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METHOD AND SYSTEM HANDLING MULTIPLE 
REGISTRATION 



FIELD OF THE INVENTION 

5 [0001] The present invention relates to telecommunications 
systems requiring to manage information related to the 
location of their users as well as information related to 
the identifiers that addresses and identify each of those 
users in said systems. More precisely, it relates with the 
10 support of multiple registrations of, at least, one user of 
one of said telecommunications system, said multiple 
registrations requested from a plurality of terminals, and 
with the further handling of multiple session establishment 
towards said plurality of terminals 

15 BACKGROUND 

[0002] Users subscribed to the services provided by a 
telecommunications system are usually assigned to 
identifiers (subscriber identifiers, subscriber identities, 
or subscriber- IDs) . For a given subscription of a user in a 

20 given telecommunication system, at least one subscriber-ID 
is used to be assigned. Said subscriber-ID (s) identify 
uniquely said subscription and is used in said system for 
addressing and identification purposes . The type, content, 
and even the number of subscriber-ID (s) per user, depends 

25 basically on the characteristics of the telecommunications 
system. 

[0003] For instance, in a telecommunications systems such 
as a Public Switch Telephone Network (PSTN) or Integrated 
Services Digital Network (ISDN) , users are assigned to one 
30 telephone number as subscriber-ID (although more than one 
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telephone number can be assigned per user in said systems) . 
These telephone numbers are according to the format 
specified in ITU-T recommendation E.164 (May 1997), and are 
assigned per user according to a specific numbering plan. 
5 Once an E.164 number is assigned to a user of a PSTN, said 
number is used both: for addressing (routing) calls to said 
user, and also to identify said user within the network. 
Since in this kind of wired systems the point in the 
telecommunications system where the user access to the 
10 service said system provides (the access point) is fixed, 
the user is supposed to be reachable in the terminal 
connected to said access point and, therefore, the user is 
usually not forced to register (attach) prior to get access 
to the services provided by the telecommunications system. 

15 [0004] In other telecommunications system, such as for 
instance in a 2G (second generation) mobile system (such as 
a Global System for Mobile communications, or GSM), or in a 
3G (third generation) mobile systems (also known as 
Universal Mobile Telecommunications System, or UMTS) , said 

20 subscriber-ID is not unique per user. A given user 
subscribed to one of said 2G or 3G systems is assigned to a 
unique private identifier (private identity or private- ID) 
and to, at least, one public identifier (public identity 
or public-ID) . 

25 Also, as opposite to traditional telecommunications systems 
using fixed (wired) access technologies (e.g.: PSTN), in 
mobile systems the same user can access to said system from 
different access points; i.e.: from different locations. 
Due to this, said user register his/her presence from a 

30 different access point in a given moment (e.g. : each time 
from the same or different terminal through the same or 
different radio access server) ; therefore, the user 
registers (attach) his/her presence in a given access point 
from a given terminal prior to access to further services, 

35 such as make or receive calls. Within said process 
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(hereinafter referred as registration), the user's terminal 
identifies the subscription he/she holds and wants to 
activate, and this is accomplished by sending (among other 
authentication and identification data) the private-ID 
5 associated to said subscription- 

Once the registration of a 2G or 3G user has run 
successfully, said user can receive incoming sessions 
(e.g.: voice calls) on his/her terminal from other users 
that have "dialled" the public-ID (or one of the public- 
10 IDs) associated to said subscription of said user. I.e.: 
the public-ID is utilized by other users as an 
aforementioned "telephone number". 

At this point, it shall be noticed that the term "session", 
whenever cited within this invention, encompasses various 

15 kind of communications that, according to the state-of-the- 
art telecommunication systems and telecommunication 
protocols, can be established between communication peers ; 
thus, being not limited to traditional "voice calls" 
provided by well known circuit-switched based systems and 

20 protocols, but also comprising communications provided by 
packet-switched (or cell -switched) based systems and 
protocols, that provides communications with multiple media 
capabilities, such as audio, video and data, even 
simultaneously within the same communication. Examples of 

25 said communications, known as "multimedia communications" 
(also as "multimedia sessions" or "multimedia calls"), are 
described, for instance, in ITU-T recommendation H.323 
(November 2000), or in IETF ' s RFC-2543 "Session Initiation 
Protocol", SIP (March 1999) . 

30 [0005] For a given subscription of a given user in a 2G or 
3G system, a given home server in the system (known as Home 
Location Register or HLR, or Home Subscriber Server or 
HSS.) keeps, among other data, and as a part of the SD 
(subscriber data) related to said subscription, the 

35 relationship between said subscription of said user and the 
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private- ID and public-ID ( s ) associated to it. Said home 
servers (for example HLRs or HSSs) are mainly in charge of 
attending request from other nodes or servers within the 
system whenever a registration request of a given user 
5 needs to be attended (i.e.: granted or rejected), or 
whenever location information of a given user is needed 
(e.g.: at call to said user). 

[0 006] In 2G or 3G systems, the private-ID of a given user 
is unique per user subscription and it is used within the 

10 2G or 3G system for internal identification purposes at 
registration, authorization, administration, etc.. 
For a given subscription, said private-ID is also stored in 
a subscriber identity module known for example as SIM, or 
USIM for 3G, which is included in the subscriber's card for 

15 example a Subscriber Identity Module card or SIM card, or 
UMTS Integrated Circuit card or UICC, provided to said 
user, together with other security information related to 
said subscription such as secret keys used for 
authentication. Said subscriber's card (SIM card, UICC) is 

20 intended to be accommodated, either: fixed or removable, in 
user's terminals used for accessing said systems. 
Unlike Public-IDs, Private-IDs does not need to be known by 
the users of said systems, nor known by other users of 
other telecommunications systems, . since they are not 

25 intended to be supplied (i.e.: "dialled") by a given user 
for establishing a communication with another user; i.e. : 
said private-IDs are not intended to be used as "called 
number", nor intended for identifying the calling or 
connected party in the end user terminal display. 

30 In 2G systems, a private-ID takes the format of IMSI 
(International Mobile Subscriber Identity) ; while in 3G 
systems, a private-ID takes the form of a NAI (Network 
Access Identifier) as defined in RFC-2486 "The Network 
Access Identifier" (January 1999), wherein the IMSI can be 

35 contained within the NAI. 
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[0007] In said 2G or 3G systems, the public-ID(s) of a 
given user is, however, intended for addressing (routing) 
calls to said user, and, therefore, intended to be used as 
"telephone numbers" are in other telecommunication systems 
j 5 for example PSTN (Public Switched Telephone Network) , ISDN 

(Integrates Services Digital Network), including calling 
and connected party identification purposes . So, public-IDs 
are used for establishing communications between users, 
and, therefore, intended to be known by the users, not only 

10 of said mobile systems (2G or 3G)', but also by users of 
other telecommunications systems which can interwork with 
said 2G or 3G systems. In this way a user (user-A) who 
wants to establish a communication with another user (user- 
B) needs to supply (i.e.: to "dial") the public-ID of said 

15 user-B (or one of the public-IDs of said user-B) in the 
call request said user-A makes. User-B, in turn, can (if 
said service is allowed) identify the calling party from 
the public-ID of user-A said user-B receives. 
The format of the public-ID (s) of a given user can vary 

20 depending on the particularities of the telecommunications 
system said user is subscribed. In 2G and 3G systems, 
public-IDs are in the format of E.164 numbers (known as 
MSISDN numbers) (i.e.: they are typical telephone numbers 
such as in PSTN) . In 3G systems that implements the so 

25 called IM Subsystem (or IMS) (Internet Protocol Multimedia 
Subsystem), said public-IDs can also take another formats, 
such as SIP-URL (Uniform Resource Locator for Session 
Initiation Protocol) , TEL-URL (Uniform Resource Locator for 
telephony) , etc . . 

30 [0008] Given that current mobile systems (2G or 3G) do 
only provide one private-ID per user subscription, and 
given that said unique private-ID is used in the 
registration process, said systems does not permit a given 
user to register into a mobile system referencing the same 

35 subscription (i.e.: by identifying the same private-ID on 
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each registration request) from more than one terminal, 
since it would imply the existence of a SIM cloning 
situation, meaning the existence of two subscription cards 
with the same data on them. Therefore (and regardless 
5 various complex techniques for SIM cloning detection) , if a " 
given user tries to register and already has a registration 
active for his/her subscription, said new registration is 
considered a re-registration and all data related to the 
old registration are overwritten with the data related to 
1 0 the new one . 

[0009] With this situation, for a given user having only 
one subscription, only one registration can be active for 
said user and said single subscription, and no simultaneous 
locations are allowed for said single subscription. In this 
15 way, a given user who wants to have more than one terminal 
registered, has to hold more than one subscription and use 
a different subscription for registering each of said 
terminals . 

[0010] Modern telecommunication systems (such as 3G mobile 
20 systems) are, however, intended to offer a huge variety of 
services. Depending on the nature of said services, some of 
them would require some capabilities within the end-user 
terminal (e.g. : a service based on multimedia capabilities 
or file/data transfer capabilities) not needed for other 
25 services (e.g. : a service based on mere voice 
capabilities) . 

This, would make desirable for a given user having one 
subscription in one of said systems to be registered from a 
plurality of terminals simultaneously (e.g.: having 
30 different capabilities each); and all this, without harming 
security aspects that rely on the identification of the 
subscription of said user nor forcing to said user to hold 
more than one subscription. 
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[0011] Fig-1 has been taken from the technical 
specification TS 23.228 (V5.0.0, April 2001) released by 
the 3 GPP (3 rd Generation Partnership Project) , which is the 
forum in charge of developing the standards ruling the 3G 
5 systems. Although this figure shows the relationship 
between private-ID and public-ID (s) of a given subscription 

(Internet Multimedia subscription, or IM-subscription) of a 
given user (IM-user) of the IMS (Internet Protocol 
Multimedia Subsystem) of a 3G system; it actually shows the 
10 state-of-the-art univocal relationship existing in mobile 
systems regardless its generation (2G or 3G) between one 
subscription and the private-ID associated to said 
subscription. Within said figure, it can be observed that, 
even though a given user holding a single subscription can 
15 be reached (i.e.: called) by means of different public-IDs, 
the subscription of said user is identified by a single 

(and only) private-ID. 

The relationship shown in Fig.l is maintained and held 
primarily in the home server of said user (HSS, HLR) , 

20 although copies of said data and relationships can also be 
kept and used in other nodes (or servers) within the 
telecommunications system. However the logic inherent to 
the aforementioned univocal relationship is deployed across 
any server within the telecommunication system, thus 

25 disabling both: to have multiple active registrations of a 
given user holding a single subscription from a plurality 
of access points, and to have subsequent calls addressed to 
said user to be delivered to one or more of said of access 
points where said user can be located. 

30 [0012] Known standards for 3G systems have regarded the 
possibility of having UMTS subscriber cards holding more 
than one subscription (i.e.: more than one US IM within the 
same UICC) (e.g.: 3 GPP TS 22.101, v4.0.0, June 2001), thus 
allowing the same terminal to be registered alternatively 
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for different user subscriptions. However, only one of 
these subscription can be active in a given moment in said 
terminal, and, in any case, the capabilities inherent to 
said terminals related to the kind of sessions it can 
5 handle remains the same regardless the active subscription. 

[0013] SIP (Session Initiation Protocol) was selected by 
3 GPP as the protocol for handling user registrations and 
session control for users holding IM-subscriptions . The 
specification of SIP (RFC-2543) already allows a given user 

10 to indicate in a registration message REGISTER multiple 
contact points where said user can be contacted (i.e.: 
reached) for further incoming sessions addressed to the 
identity (i.e.: public-ID) contained in the "From" header 
or said REGISTER message. These contact points are included 

15 in subsequent "Contact" headers within one or subsequent 
REGISTER messages, wherein each "Contact" header contains 
an address of a given SIP endpoint (i.e.: a SIP enabled 
terminal) . According to this, a SIP REGISTER message from a 
given user such as : 

REGISTER sip : server 2 . wcom . com 
Via : 

From : <sip : UserB@ there . com> 
To: .... 
Call-ID: .... 
CSeq: 1 REGISTER 

Contact : <sip: UserB@110. 111.112.113> 
Contact: tel: +1-972-555-2222 
Content-Length : .... 

if accepted by the registration server 
30 "server2.wcom.com", would make that further sessions 
addressed to said user (i.e.: further INVITE messages 
indicating in the "To" header the identity 
* "UserB@there.com") are forwarded simultaneously to both 



20 



25 
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contact points that were specified in the REGISTER message: 
the SIP application in host with IP-Addr (Internet Protocol 
address) 110.111.112.113 where said user has logged in as 
"UserB"; and to the telephone number "+1-972-555-2222 " . 
5 However, the adaptation and use of the SIP protocol to the 
specific architecture of IMS in 3G systems has blocked said 
possibility, as it can be seen in the 3GPP specification 
that states the signaling flows for IM-users (TS 24.228, 
VI. 0.0, June 2001). In said specification it is stated that 

10 the content of the "Contact" header must be the IP-Addr 
said terminal is using to access to the 3G system (i.e. the 
IP-address said terminal got during the process it ran to 
get a radio bearer packet-based, known as PDP (Packet Data 
Protocol) Context Establishment process) ; that is to say, 

15 the address it uses to exchange packets with the server 
which is serving its access to the system. 

With this limitation, a given user holding a single IM- 
subscription in a 3G system, can have only one registration 
active at the same time, said registration being related to 
20 only one access point to the system and to only one 
terminal attached to said access point and identified by a 
single address (IP- Addr) . 

[0014] Therefore, according to the state-of-the-art, a 
given user who would like to have multiple active 

25 registrations in any of said mobile systems (2G, 3G) that 
requires to manage information related to the location of 
said user for any of those registrations, as well as to 
manage information related to the identifiers that address 
and identify said user in said system, would be forced to 

30 hold different subscriptions . However, since each 
individual subscription is held separately in said systems, 
thus implying separate processing and administration (i.e.: 
separate accounting records, separate subscription records, 
separate location data, etc.) it would imply difficulties 

35 for the mobile system operator for allowing the same 
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public-ID (s) 7 related to the same user, to be assigned to 
more than one subscription; no mention to inconvenience for 
the user, having to deal with multiple bills for the same 
service. 

5 It should be then desirable a situation wherein, without 
having to appeal to a solution based on multiple 
subscriptions per user, a given user having a single 
subscription in a telecommunications system (such as a 
mobile system, or other telecommunications system of 

10 similar characteristics regarding user identities and 
location information) , is allowed to register into said 
system from different terminals simultaneously, thus having 
multiple registrations active simultaneously; and wherein 
said user can receive calls in any of these registered 

15 terminals from other parties that have "dialled" one 
public-ID that is associated to said single subscription. 

SUMMARY OF THE INVENTION 

[0015] The present invention provides a method for 
supporting multiple active registration of, at least, one 

20 user in a telecommunications system, being said 
registrations related to a single subscription of said user 
in said system and being requested each from a plurality of 
terminals (user equipment, or UE) ; and for the further 
handling of multiple session establishment towards any or 

25 each of said terminals where said user registered. The 
invention further relates to a system arranged for 
implementing said method. 

[0016] According to one aspect of the present invention, 
it is provided a method for handling multiple registration 
30 of a user in a telecommunications system that manages 
location information and identification information related 
to its users; said identification information containing at 
least, for each user, a unique private identity and one or 
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more public identities. The method comprises the steps of : 
(a) storing, assigned to said user in said 
telecommunications system, a plurality of private 
identities related to the subscriber data of said user in 
5 said system; (b) receiving subsequent registration requests, 
each registration request requesting to attach a subsequent 
terminal to said telecommunications system for said user; 
wherein each one of said subsequent registration requests 
contains, at least: a public identity associated to said 

10 user among the plurality of public identities associated to 
said user, and a private identity among the plurality of 
private identities associated to said user; and (c) 
processing each of said received subsequent registration 
requests according to the public identity and private 

15 identity received on each of said subsequent registration 
requests . 

Said method allows a given user having one subscription in 
said system to register on it from a plurality of terminals 
simultaneously; i.e.: to get granted registrations that can 
20 be active simultaneously. 

[0017] According to a further aspect of the invention, it 
is provided a method for handling session establishment 
towards a user having multiple registrations. The method 
comprises the step of (a) processing said session request 

25 according to the plurality of terminals that have a 
registration granted for said user in said system (i.e.: 
the plurality of terminals said user is presently 
registered with) ; wherein said processing step can consist 
on: (al) forwarding said session request to one of these 

30 terminals among said plurality of terminals; or (a2) 
forwarding said session request sequentially to more than 
one of said plurality of terminals until said session is 
awarded by one of them; or (a3) forwarding said session 
request simultaneously to more than one of said plurality 

35 of terminals . 
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Said method allows a given user to receive incoming 
sessions (voice calls, multimedia calls, multimedia 
conferences, data transfer, etc.) addressed to a public-ID 
of said user to be delivered to a plurality of terminals 
5 said user is presently registered with; allowing said 
session to be attended in the terminal with the best {or 
more appropriate) capabilities for said session; or simply, 
to be attended in the end-user terminal which is physically 
closest to said user. 

10 [0018] According to a further aspect of the invention, it 
is provided a telecommunications system for handling 
multiple registrations of a single subscription in said 
system. Said system comprises: (a) storage means arranged 
to store per user, at least, one or more public identities 

15 and a plurality of private identities; and (b) processing 
means arranged to process subsequent registration requests 
of a given user according to the public identity and 
according to the private identity (among said plurality of 
private identities) received on each of said registration 

20 requests . 

Said system allows multiple active registrations related to 
a single subscription. 

[0019] According to a further aspect of the invention, the 
aforementioned system for handling multiple registrations 

25 is further augmented for handling session establishment 
towards any or all the active registrations related to a 
single subscription. The system according to this aspect 
comprises (a) processing means arranged to process a 
received session request, said session request containing a 

30 public identity associated to said user, according to the 
plurality of terminals that have a registration granted for 
said user in said system; wherein said processing means can 
be further arranged to: (al) forwarding said session 
request to one terminal among said plurality of terminals; 
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or (a2) forwarding said session request sequentially to 
more than one of said plurality of terminals until said 
session is awarded by one of them; or (a3) forwarding said 
session request simultaneously to more than one of said 
' 5 plurality of terminals. 

* • said system allows to deliver an incoming session to any of 

the terminals that have a granted registration for the 
subscription addressed by the public identity indicated in 
said incoming session. 

10 [0020] According to a preferred embodiment of this 
invention, the telecommunications system comprises one or a 
set of functional server entities in charge of various 
functions, such as: 

- storing the subscriber data of the users of said system 
15 (referred also as home server entity, or HSS , HLR) , 

- serving the access to said system to the terminals (UEs) 
used by its users (referred also as first-contact-point 
server entity, or Proxy Call State Control Function, P- 
CSCF) , 

20 - serving the initial handling of transactions involving 
users of said system (referred also as interrogating 
server entity, or Interrogating- Call State Control 
Function, I-CSCF) , and 

- serving session control services for sessions involving 
25 users of said system (referred also as session-control 

server entity, or Proxy Call State Control Function, 
Serving Call State Control Function, S-CSCF) . 
If said functions are performed by a single server entity, 
or by a set of distributed or co-located functional server 
30 entities, does not affect the scope of the present 
invention. 
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BRIEF DESCRIPTION OF DRAWINGS 

[0021] The features, objects and advantages of the 
5 invention will become apparent by reading this description 
in conjunction with the accompanying drawings, in which: 

[0022] FIG. 1 shows the prior-art 1:N relationship between 
private and public identities, and 1:1 relationship between 
one IM-user subscription and its corresponding private 
10 identity as defined by aforementioned 3 GPP standard TS 
23 .228. 

[0023] FIG. 2 shows a registration flow and a further 
session establishment flow of an incoming session, as 
currently defined by 3GPP standards. 

15 [0024] FIG. 3 shows a prior-art simplified view of the 
subscriber data registers in a home server storing each the 
subscriber data a given user, wherein the content of one of 
these register is further detailed. 

[0025] FIG. 4 shows an N:N relationship between public and 
20 private identities and an 1:M relationship between one IM- 
user subscription and the private identities for said user 
subscription according to the present invention. 

[0026] FIG. 5 shows a multiple registration flow according 
to the present invention. 

25 [0027] FIG. 6 shows the same view as in Fig. 3 according to 
the present invention. 
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[0028] FIG. 7 shows data storage in various servers 
according to an optional feature of this invention • 

[0029] FIG. 8 shows a multiple session establishment flow 
according to this invention. 

5 

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS 

[0030] The invention shall now be described in detail with 
reference to figures 1 to 8 according to a preferred 
embodiment. Said preferred embodiment considers, as an 

10 example of a telecommunications system where the methods of 
this invention can apply, .a 3G mobile system that 
implements the so called (IMS) (Internee Protocol 
Multimedia Subsystem) , in which (as standardized by 3 GPP) 
the well known protocol SIP (Session Initiation Protocol) 

15 is the protocol used for handling user registrations and 
session control . for users holding IM- subs crip t i ons . 

[0031] It shall be understood that the scope of the 
present invention is not limited to said 3G systems nor to 
a specific signaling protocol; and, a skilled person can 

20 readily apply it to any telecommunications system having to 
manage data (hereinafter: subscriber data, or SD) related 
to, at least, one user holding a subscription in said 
system; said SD (subscriber data) comprising, at least, 
information related to the identifiers used in said system 

25 to identify and locate said user (private-ID, public-ID) , 
and having to manage information related to the location of 
said user. 

[0032] Said telecommunications system can, for instance 
(but not limited nor forced to) , comprise one or a set of 
30 functional server entities in charge of various specialized 
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functions, such as: storing the subscriber data of the 
users of said system, serving the access to said system to 
the terminals (UEs) used by its users, serving the initial 
handling of transactions involving users of said system, 
and serving session control services for sessions involving 
users of said system. Wherein, if said functions are 
performed by a single server entity, or by' a set of 
distributed or co-located functional server entities, does 
not affect the scope of the present invention. In 
particular, aspects concerning if said functional server 
entities are implemented in separate physical entities 
(i.e.: machines, nodes, servers) or are just implemented as 
functional entities either: co-located or distributed among 
different physical entities, as well as aspects concerning 
details of the interconnection network (or networks) that 
links said servers entities (in case they are implemented 
in separate physical entities) and aspects concerning 
details of the access technology used by the user terminals 
UE(s) to access to said system, neither affect the scope of 
the present invention. 

» 

[0033] The telecommunications system, according to the 
preferred embodiment described hereinafter, is arranged to 
manage subscriber data (SD) related to, at least, one user 
holding a subscription in said system. Said subscriber data 

(SD) comprises, at least, information related to the 
identifiers used in said system to identify and locate said 
user (private-ID, public-ID) , and information related to 
the location of said user (LOCATION DATA) . The 
telecommunication system also comprises the following 
functional server entities : 

a home server entity (HSS/HLR) , in charge of storing the 
subscriber data of the users of said system; 

a first-contact-point server entity (referred within this 
invention as Proxy-Call State Control Function or P-CSCF) , 
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in charge of serving the access to said system to the 
terminals (UEs) used by its users; 

an interrogating server entity (referred within this 
invention as Interrogating-Call State Control Function or 
5 I-CSCF) , in charge of the initial handling of transactions 
involving users of said system; and 

a session-control server entity (referred within this 
invention as Serving-Call State Control Function or S- 
CSCF) , in charge of session control services for sessions 
10 involving users of said system. 

[0034] The 3 GPP specification TS 23.002 (V5.2.0, April 
2001) defines the general network architecture of a 3G 
system, comprising the basic entities, as well as the 
specific entities belonging to the IMS defined above (P- 

15 CSCF, I-CSCF, S-CSCF, HSS/HLR) ; while general and detailed 
signaling flows are described respectively in 
aforementioned specifications TS 23.228 and TS 24.228. The 
detailed content of the messages (queries, responses, 
notifications, etc.) exchanged through the so called " CX 

20 reference point" between any of the so called Call State 
Control Functions (or CSCFs) and the HSS are further 
detailed in 3 GPP specification TS 29.228 ( V0 . 1 . 0 , June 
2001) . According to the information disclosed in 3GPP 
specifications for IMS (on its present versions) , SIP 

25 protocol is used for handling user registrations and 
session control for users holding IM-subscriptions, and 
DIAMETER protocol (IETF draft) is used at the " CX reference 
point" . 

[0035] At this point, it shall be noticed that, according 
30 to 3 GPP specifications for IMS, the various Call State 
Control Function (or CSCF) independently of their function 
(if P-CSCF, I-CSCF or S-CSCF) are referenced with their 
individual names (as it can be seen, for instance, in the 
signaling flows detailed in the aforementioned 3GPP 
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specification). Since said individual names (e.g.: a SIP- 
URL) have to be resolved (by using, for instance, Domain 
Name System, DNS, or similar technique) into the 
corresponding individual addresses (e.g.: an Internet 
5 Protocol address), they usually shall contain a domain 
portion identifying the network realm of the 3G system 
operator they belong to. For instance, a name such as "X- 
CSCF1.ZZZ.NET", wherein the "X" stands for any function 
among: proxy (P) , interrogating (I) or serving (S) , stands 
10 for a X-CSCF named "X-CSCF1" within the domain "ZZZ.NET" 
(i.e.: thus distinguished from other CSCFs with equal name 
but belonging to different domains) . In accordance with 
this, wherever in this invention it is cited a given CSCF 
name (such as for instance " P-CSCF2 " , "S-CSCF1", etc.), it 
15 shall be understood that said names may contain also a 
domain portion within its name, even though in some 
examples within this invention are not shown; being the 
relevant aspect that said names uniquely identify a given 
CSCF within a given network realm. 

20 [0036] For a better understanding of the novel methods and 
system arrangements described within this invention, 
reference shall now be made to figures 1 to 3 in order to 
illustrate the state-of-the-art handling of a registration 
procedure in a 3G system of a given user (IM-user) that 
holds a single subscription (IM-subscription) in said 
system, as well as the handling of further incoming 
sessions addressed to said user. 

In particular, Fig. 2, steps 1 to 10, shows a simplified 
signaling flow of a registration process requested by a 
given IM-user from a given terminal, UE, in a 3G system as 
a result of the processing of a registration request 
REGISTER, by the processing means on the entities depicted 
in said figure: P-CSCF, I-CSCF, HSS, S-CSCF. Details 
regarding the complete flow, can be found in 3 GPP 
35 aforementioned specifications TS 23.228 and 24.228; wherein 
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aspects that does not affect the scope of this invention, 
such as the process that the registering UE runs to get a 
radio bearer packet-based (PDP context establishment), P- 
CSCF discovery, details concerning if the user is 
5 registering from a 3G system (visited system) which is not 
the 3G system where said user has the subscription (home 
system), etc., are further detailed. With regard to this, 
and for the sake of a greater simplicity, it shall be 
noticed that, in Fig. 2, authentication sub-flows (that 

10 could run at this phase) have been also omitted. Said 
authentication sub-flows could be based, for instance, in a 
challenge/response mechanism (or any other known 
authentication mechanism) ; and could consist on an 
"authentication challenge" and the subsequent "response" to 

15 said challenge exchanged between the serving entities in 
the 3G and the registering terminal . In any case, the 
applicability or not of said authentication sub-flows does 
not affect the understanding of the prior-art flow shown in 
said figure with respect to the modifications introduced by 

20 the present invention that shall be further explained. 

[0037] In step 1 of Fig. 2 said user sends a registration 
request REGISTER, from terminal UE to the first-contact- 
point server entity P-CSCF that is serving the access of 
said UE to said system. The procedure allowing both: UE and 
25 P-CSCF to learn each other address (IP- Adclr) belongs also 
to the known art . 

The REGISTER that the UE sends contains, among other data, 
some identification data that (as it is outlined in the 
relationships shown in Fig.l) will be used by the system to 

30 identify and authenticate to the individual subscription 
said identification data belong to, and, thus, to identify 
and authenticate the user that owns said subscription. In 
particular said registration request REGISTER must contain 
(among other data) the private- ID associated to said 

35 subscription, and one public-ID among the plurality of 
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public-IDs that are associated to said subscription; since 
said information is needed to identify the subscription of 
said user, and thus, to match in the home server entity HSS 
the corresponding SD register belonging to said single 
subscription of said user, among the plurality of SD 
registers belonging to other subscriptions that are stored 
in said HSS (as shown in Fig. 3). It has to be noticed that 
the inclusion of said private-ID (and even the inclusion of 
said public-ID) in the REGISTER can be, according to some 
state-of-the-art UEs, an automatic process performed by the 
application running in the UE, wherein said data are 
extracted from the USIM contained in said UE. 

When the registration request REGISTER arrives to the first 
contact point server entity P-CSCF, said P-CSCF binds then 
the address of the registering UE with the public-ID 
received in the REGISTER and, in step 2 of Fig. 2, it then 
forwards the REGISTER to an interrogating server entity I- 
CSCF, wherein the P-CSCF has added information related to 
itself as being the first contact point server entity P- 
CSCF serving the access of said UE. Prior to said 
forwarding, the P-CSCF performs a query to the DNS (Domain 
Name System) in order to determine the right interrogating 
server entity I-CSCF where to forward said REGISTER. 

[0038] Once said registration request REGISTER arrives to 
the I-CSCF, in step3 a query is made to the HSS to 
determine the user registration status CX-Query. Said query 
comprises both data: the public-ID and private-ID received 
in the REGISTER, and will be used by the HSS to find out 
the corresponding SD register of said user. It shall be 
noticed here that implementations details regarding said SD 
register (e.g.: if there is a single register or there are 
a set of related/ linked registers per user subscription, or 
even if said registers reside in the HSS or in another data 
base) are not relevant for the understanding of the prior- 
art nor for the scope of the present invention; being the 
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relevant matter for this aspect that the subscriber data 
(SD) of a given subscription related to a given user are 
distinguished among other SDs pertaining to other 
subscriptions of other users. With regard to this, Fig. 3 
5 shows a simplified schematic view of the storage means 
containing SD of a plurality of users. In particular Fig. 3 
shows more detailed the content of a given SD register 
pertaining to the subscription of a given user (depicted as 
USER-N in the figure) on a 3G system, wherein the data 

10 stored in said register has been logically grouped into 
different classes of data according to its nature and 
functionality; however, these data can exist ordered and/or 
grouped in other ways. In Fig. 3, data stored under 
"IDENTIFICATION DATA" comprise static information related 

15 to user identities; among other data, said identification 
data comprises the public-ID (or the plurality of public- 
IDs) associated to a single subscription of a given user ( 
depicted as "User-N_PUBLIC1" , "User-N_PUBLIC2 " , in the 

figure) , as well as the single (unique) private-ID 

20 associated to said single subscription (depicted as "User- 
N_PRIVATE" in the figure). In Fig. 3, data under "LOCATION 
DATA" stores information related to the server which is 
serving an active registration of said user (if any) ; being 
its nature fully dynamic, as opposed to the static nature 

25 of the information under identification data. Belonging to 
the same SD there can be other stored data (e.g. : data 
related to the profile or profiles of said user for said 
subscription, supplementary services activation status, 
supplementary services additional data, etc.) that are not 

30 shown in detail within Fig. 3, since they are beyond the 
scope of the present invention. 

[0039] The HSS, upon the query received in step 3 of 
Fig. 2, and once the corresponding SD register has been 
found, performs a check in the location data of said SD 
35 register to verify if there is already an active 
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registration for the received private-ID "User-N_PRIVATE" . 
According to the state-of-the-art, if at this step it is 
detected in the HSS that there is an active registration 
(i.e.: location data is not empty), it is considered a re- 
5 registration, and then, the HSS answer back in step 4 with 
a registration status query response CX-Query Resp 
comprising information related to the session-control 
server S-CSCF. in charge of serving session control services 
for said user (e.g.: "S-CSCF1 .H0ME1.NET" ) , together with a 

10 registration status indication that states that said user 
is already registered. Otherwise (i.e.: location data is 
empty) , the registration status query response (CX-Query 
Resp) sent in step 4 comprises a registration status 
indication indicating that said user is not registered, 

15 together (optionally) with the capabilities for selecting a 
given S-CSCF to be assigned to serve session control 
services for said user. 

If the user is already registered (e.g. : re-registration) 
then the I-CSCF forwards in step 5 the REGISTER to the S- 
20 CSCF that was indicated by the HSS. Otherwise, it the user 
is not registered, then it selects an S-CSCF, and in step 5 
forwards said REGISTER to said S-CSCF. 

When S-CSCF receives the REGISTER, it stores the 
information included on it. In particular it stores the 

25 received private-ID and public-ID of the user who is 
registering, and information related to the P-CSCF that is 
serving the access of the UE from which said registration 
has been requested. Then the S-CSCF in step 6 notifies to 
the HSS that said user has been registered in said S-CSCF 

30 (CX-Put) ; said notification comprising the private-ID and 
public-ID received in the REGISTER, as well as information 
related to said S-CSCF, and a "server assignment type" 
field stating "registration" . 

Upon reception of said notification, the HSS finds the 
35 corresponding SD register for said user (e.g.: perform a 
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search based on the private and/or public ID) , and stores 
in the location data- of said SD register information 
stating that said S-CSCF is serving session control 
services for said user (e.g.: -S-CSCF1.H0ME1.NET"). It 
5 shall be noticed now that, as shown in the state-of-the art 
depicted in Fig. 3, only one registration can be active in a 
given moment for a given user subscription; therefore, in a 
given moment only one entry can exist within the location 
data of a given SD register (e.g.: an entry such as the 
10 entry: " S-CSCFl . HOMEl . NET {User-N_PUBLIC2 ,User-N_PRIVATE}" , 
shown in Fig. 3 for USER-N) . This causes that any entry 
previously stored in said location data to be overwritten 
at reception of a register notification (CX-Put) in the 
HSS. 

15 Next, in step 7, the HSS gives back to the S-CSCF the 
result of the registration in said HSS (accepted or 
rejected) together with data related to the user profile of 
the registering user (CX-Put Resp) . If the result of the 
registration has been successful, a registration response 

20 (200 OK) is sent back in steps 8, 9 and 10 to the UE from 
which said registration was requested. 

[0040] Once a given user has successfully registered into 
the 3G system, further incoming sessions (i.e.: voice 
calls, multimedia calls, etc.) that are addressed to the 

25 public-ID said user indicated in the registration request 
(REGISTER) shall be delivered to the UE that got the 
granted registration. Said delivery shall be made via the 
S-CSCF that was assigned in said registration, and via the 
P-CSCF that is serving the access to said UE in said 3G 

30 system and that served said registration. 

[0041] The state-of-the-art handling of a session 
establishment towards a given registered user, as a result 
of the processing of a session request ( INVITE ) by the 
processing means on the entities depicted in said figure 
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(P-CSCF, I-CSCF, HSS, S-CSCF) , shall now be described with 
reference to Fig. 2, stepsll to 16. Also Fig. 3 will be used 
to illustrate a more concrete case in which a given user 

(USER-N) , that has successfully registered using his/her 
5 private-ID (User-N_PRIVATE) and one of his/her public-IDs 

(User-N_PUBLIC2 ) , receives an incoming session. 

[0042] In step 11 a session request (INVITE) , addressed* to 
said USER-N, arrives to an I-GSCF. From where said INVITE 
is received in said J-CSCF depends on the location of the 
10 session originator. For instance, if someone in the PSTN 
made a call dialling "User-NJPUBLIC2 " (assuming said "User- 
N_PUBLIC2" is in the format of an E.164 number), then the 
INVITE arrives to the I-CSCF from a Media Gateway Control 
Function (MGCF) which, among other duties, is in charge or 
15 translating signaling protocols used in other 
telecommunications systems (such as Signaling System Number 
7) to the signaling protocol used in 3G system for 
multimedia sessions where IM-users are involved. The 
session originator could, for instance, be within a 3G 
20 system; in that case, another user has sent from his/her 
terminal an INVITE indicating in the "To" header the 
identity "User-N_PUBLIC2 " ; in that case, said INVITE can 
arrive to said I-CSCF from the S-CSCF which is assigned to 
said session originator. 
25 In any case, the location of the session originator , as 
well as signaling flows or details previous to the arrival 
of said INVITE to the I-CSCF, are not relevant for the 
understanding of the prior-art shown in Fig. 2 nor for the 
modifications introduced by the present invention in said 
30 prior-art that shall be further explained. 

[0043] Then, in step 12, the I-CSCF sends a location query 

(CX-Location Query) to the HSS to find out the S-CSCF that 

is assigned to serve session control services for the 

called user, wherein said query comprises the public-ID 
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received in the INVITE (e.g.: User-N_PUBLIC2 ) to identify 
said called user in the HSS . The HSS then locates the 
corresponding SD register of said called user (USER-N) that 
matches said public-ID and finds there is a S-CSCF assigned 
5 to said user (e.g.: "S -CSCFl.HOMEl.NET" ) , and in step 13 
the HSS sends back a location query response (CX-Location 
Query Resp) comprising information related to said S-CSCF. 

[0044] Upon reception of the location query response, the 
I-CSCF in step 14 forwards the INVITE to the S-CSCF 
10 indicated by the HSS. Then said S-CSCF looks in the stored 
information related to P-CSCFs it has, the particular P- 
CSCF through which a registration was requested (REGISTER) 
and granted (2 00 OK) that contained the public-ID 
referenced in the INVITE, and forwards in step 15 the 
15 INVITE to it. Upon reception of the INVITE in the P-CSCF, a 
similar procedure is performed to find out in said . P-CSCF 
the address (IP- Addr) of the terminal <UE) that got 
granted a registration indicating said public-ID, and in 
step 16 forwards the received INVITE to said UE. 

[0045] A given user registered into a 3G system can become 
de-registered from said system either: upon user request, 
made from the registered terminal (user-initiated de- 
registration) ; or upon 3G system decision (network- 
initiated de-registration) . Either: user-initiated or 
network- initiated de-registration, the state-of-the-art de- 
registration procedures causes a deletion of the location 
data stored in the SD register associated to said user; 
i.e.: "LOCATION DATA" of USER-N shown in Fig. 3 becomes 
empty, since, as mentioned before, only one entry in said 
location data exist. Also, user-initiated or network- 
initiated de-registration causes the deletion of previously 
bound data in the S-CSCF and in P-CSCF which were serving 
said registration. So, in the S-CSCF it is deleted the 
previously stored information that bound the public and 
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private IDs used in the registration with the P-CSCF 
serving the access to said registration. Similarly, in the 
P-CSCF it is deleted the previously stored information that 
bound public and private IDs used in the registration with 
the address of the UE that requested said registration. 
A user-initiated de-registration procedure (not shown in 
Fig. 2) runs in a similar manner as the registration 
procedure does: a REGISTER is received from an already 
registered UE indicating an expiration value ("Expires" 
header) of zero (0) . A similar flow as the one depicted in 
Fig. 2, steps 1 to 4 is executed that determines the S-CSCF 
which is currently serving the active registration of said 
user. Said S-CSCF then sends a notification to the HSS 
indicating that said user has been de-registered from said 
15 S-CSCF (CX-Put) , wherein said notification this time 
comprises a "server assignment type" field stating "de- 
registration", together with the aforementioned 
identification data related to the de-registering user and 
to the S-CSCF. 

20 [0046] Reference is now made to figures 4 to 6 to 
illustrate a novel method and system arrangements according 
to the present invention for handling multiple 
registrations in a 3G system of a given user (IM-user) that 
holds a single subscription ( IM-subscription) in said 

25 system. 

For said single subscription of said user, a plurality of 
private-IDs are defined and stored in the storage means of 
the HSS that is assigned to store the subscriber data (SD) 
of said user for said subscription; thus allowing, as shown 
schematically in Fig-4, said subscription to be referenced 
(i.e.: registered, called) by means of any of the plurality 
of identifiers associated to it. Within said Fig. 4, that 
should be compared with Fig.l that shows the correspondent 
prior art for the same abstraction, multiple registrations 
of the same given subscription of said user can be held, 
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given that each registration references a different 
private-ID among the plurality of private-IDs that are 
associated to it ("Private user identity 1", " Private user 
identity 2", " Private user identity 3"). Correspondingly, 
5 and as will be further detailed, further sessions addressed 
to the public-ID of this user, or (as an implementation 
option) to any of the public-IDs of this user ("Public 
user identity 1", " Public user identity 2") shall be held 
taking into consideration said multiple registrations. For 

10 instance, and as indicated by the dots shown within Fig. 4, 
a session addressed to "Public user identity 1", can be 
handled according to registration status of "Private user 
identity 1" and " Private user identity 2", while session 
addressed to "Public user identity 2" can be handled 

15 according to registration status of "Private user identity 
3"; although (as an implementation option) any of those 
sessions can also be handled according to the registration 
status of any or all of the private-IDs associated to said 
subscription. 

20 [0047] The multiple registration process in a 3G system of 
a given user that holds a single subscription in «aid 
system shall now be described with reference to the 
simplified signaling flow shown in Fig. 5. References shall 
also be made to Fig. 6 to exemplify a specific case of a 

25 given user (USER-N) . In particular, Fig. 5, shows a 
simplified signaling flow of a registration process 
requested by a given IM-user from a plurality of terminals 
(UE1,UE2,UE3) in a 3G system as a result of the processing 
of subsequent registration requests (REGISTER) by the 

30 processing means on the entities depicted in said figure 
(P-CSCFs,I-CSCF,HSS,S-CSCFs) . 

As previously done for equivalent state-of-the-art Fig. 2, 
and also for the sake of a greater clearness that helps to 
highlight the novel aspects described hereinafter, Fig. 5 
35 does not show any authentication sub-flow. However, those 
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skilled in the art who are familiar, for instance, with the 
detailed registration flows described in 3 GPP specification 
TS 24.228, will easily understand how the methods described 
within this invention can equally apply if said 
authentication procedures take place. For example, for each 
registration, said authentication sub-flows can consist on 
additional messages exchanged between the serving entities 
shown in Fig. 5 and the registering terminal (s) (e.g.: a 
challenge /response mechanism) that could convey private or 
public identities used in the registration. In that case, a 
"challenge response", sent from a registering terminal as a 
result of a received "authentication challenge", could be 
embedded within a new registration request REGISTER that, 
as explained previously, would have to convey a private 
15 identity and (at least) a public identity to identify the 
particular subscription said identities belong to; although 
other method could be used. In any case, given that an 
authentication procedure (if used) would always be 
associated to a registration request, being identities 
related to a given subscription always referenced in said 
registration request; if said authentication procedure 
takes place or not, does not affect the basic processing of 
a registration request based on private and public 
identities referenced on it, which is one of the objects of 
25 the present invention. 

E0048] Within Fig. 6 (that will be further referenced in 
relation to detailed descriptions of further aspects of 
this invention) it is shown a simplified schematic view of 
the storage means containing SD of a plurality of users. In 
particular Fig. 6 shows more detailed the content of the SD 
register of given user (USER-N) , wherein, according to the 
present invention, a plurality of private-IDs have been 
assigned (User-N_PRIVATE1 , User-N_PRIVATE2 , User- 

N_PRIVATE3) for said user in relation to the identification 
data of his/her subscription. It shall be noticed that, 
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although three private-IDs are shown in this example, a 
higher or lower number of private-IDs assigned per 
subscription is an aspect that does not affect the scope of 
the present invention. The identification data of said 
5 subscription also comprises plurality of public-IDs (User- 
N_PUBIiICl, User-N_PUBLIC2) ; although, for the fundamental 
scope and understanding of the present invention, it is not 
relevant if there are more than one public-IDs associated 
to a given user. 

10 Fig. 6 (as opposed to Fig. 3) also shows that, according to 
the present invention, the location data of a given SD 
register can comprise a plurality of entries; more 
precisely, it can comprise information related to a 
plurality of S-CSCFs and a plurality of identities 

15 (private-IDs, public-IDs) ; wherein, as will be further 
explained, each S-CSCF stored in the location data of said 
SD register has been assigned to serve session control in 
subsequent registrations of the same user (the user said SD 
register belongs to), said subsequent registrations 

20 indicating each a different private-ID assigned to the 
subscriber data of said user, among the plurality of 
private-IDs assigned to the subscriber data of said user. 

[00493 As shown in Fig. 5, steps 1, 7 and 13, said user 
(USER-N) sends subsequent registrations requests (REGISTER) 

25 from subsequent terminals (UEl , UE2 , UE3 ) via different P- 
CSCFs (P-CSCF1,P-CSCF2,P-CSCF3) , indicating on each of said 
registrations, at least, one public-ID and one private-ID, 
among the plurality of public-IDs and private- IDs 
associated to said user. The specific case shown within 

30 this figure, in which three registration flows are 
displayed as an example, shall not be considered as 
limiting the scope of the present invention, since, as it 
shall be further understood, the methods disclosed 
hereinafter applies whenever more than one registration 

35 request is received for the same user. 
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It has to be noticed that, for every . successful 
registration request shown in Fig. 5, there is a 
registration confirmation flow (not shown) similar to the 
one shown in Fig. 2 steps 7 to 10, each of said confirmation 
5 flow going back to the terminal that gets the granted 
registration (UE1, or UE2, or UE3) through the CSCFs 
intervening in said granted registration. Aspects such as: 
if the same P-CSCF is serving the access to more than one 
of these UEs, or even to all of them, or if there is a 
10 different P-CSCF serving the access to each one of these 
UEs; are regarded by the present invention, as it shall be 
understood hereinafter. 

[0050] For a better ' understanding of the process, it can 
be assumed that, prior to the signaling flow of Fig. 5, said 

15 user has not any active registration yet; i.e. : it is not 
registered yet with any of the private-IDs associated to 
said user, and thus, the location data in the SD register 
corresponding to said user is still empty (e.g. : location 
data of USER-N shown in Fig. 6 does not contain any data 

20 yet) . 

Steps 1 to 3 of Fig. 5 are similar to equivalent steps 1 to 
3 of the registration request - explained previously with 
reference to Fig. 2. In the specific case shown in Fig. 3, a 
terminal (UE1) sends a registration request (REGISTER) 

25 through a given P-CSCF (P-CSCF1) . As mentioned above with 
reference to the prior-art flow in Fig. 2, the P-CSCF 
receiving a REGISTER binds the address of the terminal with 
the public-ID indicated in the received REGISTER. 
The HSS, upon reception of the registration query made by 

30 the I-CSCF in step 3 (CX-Query) , locates then the SD 
register of the user referenced by the private-ID and 
public-ID received in said query. Considering the specific 
case mentioned above to illustrate the flow, and assuming 
that the private-ID received is "User-N_PRIVATEl n and the 

35 public-ID received is » User-N_PUBLIC2 " , then the SD 
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register of USER-N shall then be encountered by the HSS 
among the plurality of SD registers belonging to 
subscriptions of other users. To find out said SD register 
the HSS does not need to use any novel technique; any 
5 state-of-the-art . search technique based on the received 
private-ID and/or the received public-ID can be used for 
said purpose. 

[0051] Once said SD register have been found, it is 
checked in the location data of said SD if said user is 

10 already registered with the received private-ID (User- 
N_PRIVATE1) ; that is to say, if there is already a S-CSCF 
assigned to serve session control services for the received 
private-ID User-N_PRIVATE1 (i.e.: any entry in the location 
data that contains said received private-ID) . Considering 

15 the assumption made above, at this stage, the location data 
in said register is still empty; therefore, in step4 a 
registration query response (CX-Query Resp) is sent to the 
I-CSCF comprising: a registration status indication, 
stating that USER-N is not registered with said received 

20 private-ID, and (optionally) the capabilities required for 
selecting from said I-CSCF an S-CSCF that will finally 
support for said registration session control for further 
sessions involving said user for said received private-ID 
(User-N_PRIVATE1) and public-ID (User-N_PUBLIC2 ) . 

25 Since the registration status indication states that the 
registering user is not registered with said received 
private-ID, and no S-CSCF is indicated by the HSS on the 
registration query response, the I-CSCF, using state-of- 
the-art techniques for selecting an S-CSCF when no S-CSCF 

30 is provided by the HSS (e.g.: based on the capabilities 
received from the HSS) , selects an S-CSCF and forwards the 
INVITE to said selected S-CSCF in step 5 . . In the example 
shown in Fig. 5 said selected S-SCCF is "S-CSCFl n . 
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[0052] Then, the selected S-CSCF (S-CSCFl) stores 
information related to the P-CSCF serving said registration 
(P-CSCFl) as well as the private and public IDs indicated 
on it (User-N_PRIVATE1, User-N_PUBLIC2 ) and, in step 6, 
notifies (CX-Put) to the HSS that said S-CSCFl will serve 
sessions involving said private-ID (User-N_PRIVATE1) and 
said public-ID (User-NJPUBLIC2 ) . Said notification (CX- 
Put) , as well as the other "CX-put" notifications shown in 
the flow depicted in Fig. 5 comprise: the private-ID and 
public-ID received in the REGISTER which is being 
processing, as well as information related to the S-CSCF 
that sends said "CX-Put" , and a "server assignment type" 
field stating "registration". 

The HSS then finds out the corresponding SD register and 
stores in the location data of said register a new entry- 
stating that said "S-CSCFl" (shown in Fig* 6 as "S- 
CSCF1.H0ME1.NET") is serving session control for said user 
(USER-N) , and said identifiers: "User-N_PUBLIC2 " and "User- 
N_PRIVATE1" (shown in Fig. 6 as location data entry 
comprising " S-CSCFl . HOME1 . NET { User~N_PUBLIC2 , User- 
N_PRIVATE1) ) . As an implementation option, the HSS can 
make said S-CSCF to serve sessions addressed to said user 
to any of the public-IDs associated to said user, as will 
be further explained. Next, the registration of said user 
(OSER-N) from said terminal (UE1) is granted ("200 OK", not 
shown) . 

[0053] Steps 7, 8 and 9 are equivalent to equivalent steps 
1 to 3 detailed above. In this case, the registration 
request (REGISTER) is sent from a subsequent terminal (UE2) 
through a given P-CSCF (P-CSCF2) which, in the example 
shown in the figure, appears to be different from the one 
the previous registration request was made (P-CSCFl) . Said 
difference can be due to several factors that does not 
affect the scope of the present invention (e.g.: UE1 and 
UE2 are accessing the same home 3G system from different 
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visited 3G systems; or UE1 and UE2 are in different 
location areas within the same system, assigned each to a 
different P-CSCF. However, since a P-CSCF adds information 
related to itself when it forwards a registration request 
5 to an I-CSCF (as previously explained with reference to 
step 2 of Fig.2), and this information will be received and 
kept by the S-CSCF selected for said registration (together 
with the public and private IDs indicated in said 
registration) ; in case of multiple registrations for the 
10 same user, it is not relevant if the P-CSCF serving access 
in a subsequent registration is the same or a different P- 
CSCF as the one(s) used for previous active 
registration (s) , given that said P-CSCF shall be uniquely 
identified in the corresponding S-CSCF (the S-CSCF selected 
15 for said subsequent registration) as serving an active 
registration for a certain private-ID and a certain public- 
ID. 

[0054] Following with the aforementioned specific case 
used as example, we can assume now that the REGISTER 
contains "User-N_PRIVATE2 " as private-ID and "User- 
N_PUBLIC1" as public-ID. When the registration query (CX- 
Query) of step 9 is received in the HSS, then the SD 
register of USER-N is identified by using existing 
techniques based on the received identities, as mentioned 
above. 

Once said SD register has been found, the HSS checks if the 
received private-ID ( "User-N_PRIVATE2 n ) is already 
contained within the location data of said SD. Should this 
be the case, then, as mentioned previously with reference 
to step 3 of Fig.2 (re-registration case) , the HSS would 
answer back in step 10 with a registration status query 
response (CX-Query Resp) comprising information related to 
the S-CSCF in charge of serving session control services 
for said user, together with a registration status 
indication that states that said user is already 
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registered. However, assuming the specific case shown 
within this example, said private-ID ( M User-N._PRIVATE2 " ) is 
not yet contained within the location data of said SD; 
therefore, in step 10 a registration query response (CX- 
5 Query Resp) is sent to the I-CSCF comprising: a 
registration status indication, stating 'that USER-N is not 
registered with said received private-ID, and (optionally) 
the capabilities required for selecting from said I-CSCF an 
S-CSCF that will finally support for said registration 
10 session control for further sessions involving said user 
for said received private-ID (User-N_PRIVATE2) and public- 
ID (User-N_PUBIjICl) . 

In the particular case shown with reference to Fig. 5, since 
the location data of said SD register of said USER-N is not 

15 empty at this stage, the HSS can also provide to the I-CSCF 
a list comprising information related to one or more of the 
S-CSCF (s) that are referenced in said location data. This 
can be useful, for instance, whenever a policy for 
assigning always the same S-CSCF to the same user for all 

20 his/her registrations is deployed. In the particular case 
cited as example, said list would comprise information 
related only "S-CSCF1V 

The I-CSCF then, since the registration status indication 
states that the registering user is not registered with 

25 said received private-ID, selects an S-CSCF and in step 11 
forwards the received REGISTER to it. For selecting an S- 
CSCF, the I-CSCF • can either: use state-of-the-art 
techniques for selecting an S-CSCF when no S-CSCF is 
provided by the HSS (e.g. : based on the capabilities 

30 received from the HSS) ; or, in case information related to 
one or more S-CSCFs is received from the HSS, choose one of 
them. As it can be understood, the latest case would be 
useful for implementing the aforementioned policy of 
assigning always the same S-CSCF to the same usc-^r. 
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In the example shown within this flow, it has been assumed 
that the I-CSCF has, for instance, selected an S-CSCF based 
on the capabilities received from the HSS. I.e.: other 
policy, different from the one posed above is applied. In 
5 the example, said selection has resulted in that " S-CSCF2 " 
has been finally chosen; however, as will be later 
understood, another S-CSCF could have been selected, that 
could be the same of different as the one serving said user 
for the previous registration (S-CSCF1) , without affecting 
10 at all the scope of the multiple registrations of USER-1 
and the handling of further calls addressed to said user 
for any of said multiple registrations. 

[0055] The S-CSCF selected for this registration (S-CSCF2) 
acts similarly as described above for the previous 

15 registration. It first stores information related to the P- 
CSCF that is serving this registration (which in the case 
used as example is "P-CSCF2" for this registration), as 
well as the private and public IDs indicated on it (User- 
N_PRIVATE2, User-NJPUBLICl ) and, in step 12, notifies (CX- 

20 Put) to the HSS that said S-CSCF2 will serve sessions 
involving said private-ID (User-N_PRIVATE2 ) and said 
public-ID (User-N_PUBLIC1) . 

The HSS finds out the corresponding SD register and creates 
a new location data entry in said SD register, said new 

25 entry storing information stating that said n S-CSCF2" 
(shown as "S-CSCF2.HOMEl.NET" in Fig. 6) is serving session 
control for said user (USER-N) , and said identifiers: 
"User-N_PUBLIC1" and "User-N_PRiVATE2 " (shown in Fig. 6 as 
location data entry comprising "S-CSCF2.HOMEl.NET {User- 

30 N_PUBLIC1 , User-N_PRIVATE2 } ). As shown in Fig. 6, and as 
opposed to the aforementioned prior-art techniques, it can 
be observed that, each registration made for each of the 
private-IDs of the same user causes a new location data 
entry to be created, said entry storing information about 

35 the S-CSCF assigned to serve session control for further 
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sessions related to said registration, as well as 
information about the identities (public-ID, private-ID) 
indicated in said registration. As an implementation option 
mentioned before, the HSS can later make any of said S- 
5 CSCFs to serve sessions addressed to any of the public- IDs 
associated to said user, as will be further explained. 
Next, the registration of said user (USER-N) from said 
terminal (UE2) is granted ("200 OK", not shown). 

[0056] For the third registration flow shown in the 
10 example of Fig. 5 , the registration request (REGISTER) is 
sent from a subsequent terminal (UE3 ) through a given P- 
CSCF (P-CSCF3) in which, similarly to previous registration 
(steps 7 to 12), it has been depicted as requested through 
a P-CSCF different from the ones used in previous 
15 registrations. In this case we can assume that the private- 
ID indicated in said REGISTER is n User-N_PRIVATE3 " and the 
public-id is "User-N_J?UBLIC2 " . 

Steps 13, 14 and 15 are similar to equivalent steps of the 
previous registrations, wherein only the content of the 

20 REGISTER varies. 

In this case, as well as for all the registrations of any 
user, and independently if said user is already registered 
with any private-ID or not, upon reception of a 
registration query (CX-Query) in step 15, the HSS will 

25 first locate the SD register that correspond to the 
identities received in . the register request, and then check 
in said SD register if the private-ID received in said 
register request ( "User-N_PRIVATE3 " ) is already within any 
of the entries stored in the location data of said SD. For 

30 this subsequent (third) registration, as well as for the 
previous subsequent registration explained with reference 
to steps 7 to 12 (second), the location data of said SD 
register of said USER-N is not empty, containing in this 
particular case, two entries ( n S-CSCF1 . HOMEl . NET {User- 

35 N_PUBLIC2 , User-N^PRIVATEl } ", and " S-CSCF2.HOMEl.NET 
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{User-N_PUBLIC1 , User-N_PRIVATE2) " ) , each entry in said 

location data referencing an active registration. 

The HSS then in step 16 sends a registration query response 

(CX-Query Resp) to the I-CSCF comprising: a registration 
5 status indication, stating that USER-N is not registered 
with said received private-ID (User-N_PRIVATE3 ) , and 

(optionally) the capabilities required for selecting from 
said I-CSCF an S-CSCF that will finally support for said 
registration session control for further sessions involving 
10 said user for said received private-ID (User N_PRIVATE3 ) 
and public-ID (User-N_PUBLIC2 ) . 

Since the location data of said SD register of said USER-N 
is neither empty in this case, in the query response the 
HSS can also provide to the I-CSCF a list comprising 
15 information related to one or more of the S-CSCF (s) that 
are referenced in said location data. So, in this case said 
list can comprise information related only to n S-CSCFl n , 
only to "S-CSCF2", or to both of them. 

In case a policy is wanted in which all the registrations 
20 of a given user that indicate the same public-ID are 
assigned to the same S-CSCF, then said list shall contain 
information related to the S-CSCF which is already assigned 
to serve session control related to a previous registration 
that indicated said public-ID (if any) . In this specific 
25 example case, said list would contain information related 
only to "S-CSCF1" , since, at the moment this third 
registration request is handled, an S-CSCF (S-CSCFl) have 
been already assigned for a previous registration that 
contained the same public-ID (User-N_PUBLIC2) as the 

30 present one. 

In the example shown in Fig. 5, in step 17 the I-CSCF 
forwards the registration request to S-CSCFl . This 
behaviour shows a policy for selecting an S-CSCF when both: 
S-CSCF capabilities, and information related to S-CSCF (s) 

35 is present in the " CX-Query Resp", different from the one 
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described for the previous (second) registration with 
reference to equivalent step 11 (i.e.: no S-CSCF is 
selected based on received S-CSCF capabilities if S-CSCF(s) 
is (are) indicated from the HSS) ; being in this case the 
5 result of said policy that all registrations of a given 
user indicate the same public-ID are assigned to the same 
S-CSCF. 

[0057] The S-CSCF selected for this registration (S- 
CSCF1), first stores information related to the P-CSCF that 

10 is serving this registration (which in the case used as 
example is "P-CSCF3 " for this registration), as well as the 
private and public IDs indicated on it (User-N_PRIVATE3 , 
User-N_PUBLIC2) and, in step 18, notifies (CX-Put) to the 
HSS that said S-CSCFl will serve sessions involving said 

15 private-ID (User-N_PRIVATE3 ) and said public-ID (User- 
N_PUBLIC2) . 

Then, once the HSS finds out the corresponding SD register/ 
it creates a new location . data entry in said SD register, 
said new entry . storing information stating that said "S- 

20 CSCFl" (shown as "S-CSCF1.H0ME1.NET" in Fig. 6) is serving 
session control for said user (USER-N) , and said 
identifiers: "User-N_PUBLIC2 " and "User-N_PRIVATE3 " (shown 
in Fig. 6 as location data entry comprising "S- 
CSCFl.HOMEl.NET {User-N_PUBLIC2 , User-N_PRIVATE3 } ) . As an 

25 implementation option mentioned above, the HSS can make any 
of said S-CSCFs to serve sessions addressed to any of the 
public-IDs associated to said user, as will be further 
explained. 

Next, the registration of said user (USER-N) from said 
30 terminal (UE2) is granted ("200 OK", not shown). 

[0058] As an optional further feature that can, for 
instance, facilitate look-up searches at further sessions 
requested towards any of the public-IDs of a given user 
that has got multiple registrations (multi-registered 
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user) , the HSS can build a look-up table that binds each 
public-ID of said user with a list containing information 
related to each S-CSCF that was stored in said HSS as 
assigned to serve session control for further sessions 
5 addressed to said user for said public-ID (if any) . Said 
list can, for instance, be built /updated upon subsequent 
registration notifications (CX-Put) received from S- 
CSCF(s) . An example of an entry in said table in the HSS is 
shown in Fig. 7 [A], wherein it is displayed the list of S- 
10 CSCFs ( S-CSCFl , S-CSCF2 , . . . , etc . ) currently serving a given 
public-ID (User-N_PUBLIC2) . 

Similarly, and with the same purpose, similar tables can be 
maintained in S-CSCFs and P-CSCFs for every granted 
registration. A S-CSCF would then bind a given public-ID 

15 with a list containing information of each P-CSCF trough 
which a registration containing said public-ID was granted 
from said S-CSCF. Said list can, for instance, be 
built/updated at the moment a registration is granted ("200 
OK" sent) . An example of an entry in said table in a given 

20 S-CSCF is shown in Fig. 7 [B] , wherein it is displayed the 
list of P-CSCFs (P-CSCF1,P-CSCF2, . . . ,etc. ) currently 
serving a given public-ID (User-N_PUBLIC2 ) . 

On the other hand, a P-CSCF would then bind a given public - 
ID with a list containing the individual IP- Addr of each 

25 terminal (UE) that have got a granted registration through 
it and have used said public-ID in the granted 
registration. Said list can, for instance, be built /updated 
at the moment a registration is granted ("200 OK" received, 
or "200 OK" sent) . An example of an entry in said table in 

30 a given P-CSCF is shown in Fig. 7 [C] , wherein it is 
displayed the list of addresses (P-ADDR UE1, IP -ADDR 
UE2,..., etc.) of the UE(s) that got a granted registration 
through it and indicated, for instance, "User-N_PUBLIC2 " as 
public -ID. 
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[0059] Reference is now made to Fig. 8 to illustrate, 
according to the present invention, the handling of 
multiple session establishment towards a given user that 
has got multiple registrations (multi-registered user) ; as 
opposed to the state-of-the-art single session 
establishment towards a user who has a single registration 
previously described with reference to Fig. 2, steps 11 to 
16. In particular, Fig. 8, shows a simplified signaling flow 
of a session establishment process requested towards a 
given IM-user from a plurality of terminals (UEl, UE2 , UE3 ) 
in a 3G system as a result of the processing of a session 
request (INVITE) by the processing means on the entities 
depicted in said figure (P-CSCFs, I-CSCF, HSS, S-CSCF) . For 
the sake of a better understanding, the aforementioned 
example case of an already multi-registered user ( as 
described previously for USER-N) shall be used to exemplify 
a specific case. 

[0060] As cited previously with reference to the prior-art 
depicted in Fig. 2, the location of the session originator 
(i.e.: the calling party), as well as signaling flows or 
details previous to the arrival of the session request 
(INVITE) to an I-CSCF, does not affect the scope of the 
present invention . 

Steps 1 and 2 in Fig. 8, are similar to equivalent steps 11 
and 12 in Fig. 2; so, in step 2 of Fig. 8, the I-CSCF sends a 
location query (CX-Location Query) to the HSS, said query 
comprising the public-ID received in the INVITE (e.g. : 
User-N_PUBLIC2) . The HSS, by using state-of-the-art 
techniques, first finds out the corresponding SD register 
(SD register of USER-N), i.e.: the SD register that 
contains on its identification data the public-ID received 
in the query; and then, looks into the location data of 
said register to determine which S-CSCF (or plurality of S- 
CSCFs) is (are) already assigned to serve session control 
for said user and for said received public-ID. Assuming, as 
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an example, that the public-ID received is "User-NJPUBLIC2 ■ 
(belonging to USER-N) , then, assuming also said USER-N has 
got multiple registrations as described previously with 
reference to Fig. 5, it should be found that S-CSCF2 (S- 
5 CSCF2.HOMEl.NET) is presently in charge of serving session 
controls that involve said user for two registrations that 
were made indicating said public-ID (entries: "S- 
CSCF1 . H0ME1 . NET {User-N_PUBLIC2 , User-N_PRIVATE1 } " , and 
- S-CSCF1 . HOME1 . NET {User-N_PUBLIC2 , User-N_PRZVATE3 } n 

10 shown in the location data of USER-N in Fig. 6). 

Alternatively, for the purpose of finding out quickly in 
the HSS what S-CSCF(s) are presently assigned to serve 
session control for a given user and a given public-ID 
associated to the identification data of said user, the HSS 

15 can use the location information stored in the 
aforementioned look-up table- (Fig. 7 [A]) that relates 
public-IDs with the corresponding assigned S-CSCF(s) . 

[0061] Even though in the specific case used as example 
only one S-CSCF> (S-CSCF1) is found for said user (USER-N) 

20 and said received public-ID (User-N_J?UBLIC2 ) ; there could 
be the case wherein more than one S-CSCF is found as 
serving the same public-ID for said user (for instance, S- 
CSCF1 and S-CSCF2) . In this case, and according to an 
embodiment of this invention, the HSS would send back in 

25 step 3 a location query response (CX-Location Query Resp) 
to the I-CSCF comprising information related to only one S- 
CSCF among the plurality of S-CSCFs in charge of serving 
session control for said user and said public-ID. 
Therefore, according with this embodiment, and in the 

30 specific case used as example, the HSS would send back in 
step 3 a location query response (CX-Location Query Resp) 
to the I-CSCF comprising information related (only) to S- 
CSCF1 . 

However, and according to an alternative embodiment of this 
35 invention, the HSS can send back in step 3 a location query 
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response (CX-Location Query Resp) to the I-CSCF comprising 
a list with information related to more than one S-CSCF 
among the plurality of S-CSCFs serving session control for 
said user and said public-ID, or even comprising 
5 information related to all of said S-CSCFs. Conditions for 
the execution or not of this alternative embodiment can be 
settled on a per user basis (e.g. : based on the user 
profile data handled by the HSS) or as a general 
implementation for all the users; being in any case useful 
10 whenever, for instance, it is wanted (either: by the user 
or by the network operator) a high degree of availability 
for answering terminating sessions . 

[0062] According to further another alternative embodiment 
the location query response (CX-Location Query Resp) sent 

15 from the HSS to the I-CSCF in step 3, can comprise 
information related to one, or more than one 7 S-CSCF (s) 
which is (are) in charge of serving session control for any 
of the public-IDs assigned to said user. In this case, 
since (as mentioned earlier for the registration procedure) 

20 for every activfe registration: in a given S-CSCF, there is 
a binding between a given public-ID indicated in a 
successful registration and the P-CSCF involved in said 
registration; and, in a given P-CSCF, there is a binding 
between a given public-ID indicated in a successful 

25 registration and the address of the UE involved in said 
registration; whenever the HSS sends information related to 
an S-CSCF which is serving said user, but for a public-ID 
different from the one received in the location query, the 
HSS will accompany the information related to said S-CSCF 

30 with the public-ID said S-CSCF is serving for said user. 
For instance, in the specific case cited above, and 
considering the location data shown in Fig. 6 for the multi- 
registered USER-N, should the HSS send a location query 
response (CX-Location Query Resp) comprising information 

35 related to S-CSCF2, it should include the public-ID "User- 
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N_PUBriICl" accompanying to the information related to said 
S-CSCF2 . 

[0063] Procedures in the I-CSCF at reception of the 
location query response (CX-Location Query Resp) depends on 
5 the information related to S-CSCF (s) received in said 
response. 

When the location query response (CX-Location Query Resp) 
contains information related to only one S-CSCF, the r-CSCF 
forwards the received session request (INVITE) to the S- 

10 CSCF indicated by the HSS in said query response. If, 
however, said response contains information related to a 
plurality of S-CSCFs, the I-CSCF can implement different 
options that (as mentioned above) can be deployed, for 
instance, according to the aforementioned high or low 

15 degree of availability wanted for answering terminating 
sessions. 

According to an embodiment of this invention, the I-CSCF 
selects one S-CSCF among said plurality of S-CSCFs 
indicated by the HSS, and forwards the received INVITE to 
20 it. 

According to further another alternative embodiment, the I- 
CSCF forwards the INVITE simultaneously to more than one of 
said plurality of S-CSCFs. In this case, as soon as the 
session is awarded (i.e: answered or accepted) (e.g.: 
25 reception of SIP response code "200 OK" from one of said S- 
CSCFs) , the I-CSCF can tear down the session requests it 
had sent to the other S-CSCFs (e.g.: sending a SIP cancel 
request " CANCEL " to said S-CSCFs) . 

According to further another alternative embodiment, the I- 
30 CSCF forwards the INVITE sequentially to more than one of 
said plurality of S-CSCFs until the INVITE is awarded by 
one of them; for instance: until a positive response code 
(such as "200 OK"), is received. For this purpose, the I- 
CSCF can, for instance, set a timer of a pre-defined value 
35 when it sends the INVITE to a first S-CSCF; so, once a 
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given period of time has elapsed without receiving said 
positive response (time-out) , or a negative response have 
been received (e.g.: a SIP response code "4XX"), it shall 
forward the INVITE to a second S-CSCF, etc.; thus 
5 proceeding correspondingly with the subsequent S-CSCFs. ? 
Optionally, the I-CSCF can tear down the session request it 
forwarded to a given S-CSCF at time-out (e.g.: sending a 
SIP cancel request "CANCEL" to said S-CSCF) . 

In any of the aforementioned cases (INVITE forwarded to one 
10 S-CSCF, or forwarded simultaneously or sequentially to more 
than one S-CSCF) , whenever the I-CSCF forwards the session 
request (INVITE) to a S-CSCF that was indicated by the HSS 
with a public-ID different from the public-ID received in 
said INVITE (i.e.: said S-CSCF is serving the same user but 
15 for a different public-ID) ; then, the INVITE said I-CSCF 
forwards to said S-CSCF shall contain the public-ID 
received from the HSS in replacement of the public-ID 
originally received in the INVITE. 

Referring now to the specific case depicted in Fig. 8, since 
20 the location query response (CX-Location Query Resp) have 
been previously assumed to contain information related only 
to S-CSCF1 (being, according to the example, no another 
public-ID accompanying said information) , the I-CSCF 
forwards in step 4 the received INVITE to said S-CSCFl . 

25 [0064] When the session request (INVITE) arrives to the S- 
CSCF, it finds out in the stored information it has related 
to P-CSCFs, the P-CSCF (or plurality of P-CSCFs) through 
which a registration was requested (REGISTER) and granted 
(20 0 OK) that contained the public-ID received in said 

30 INVITE. Assuming, as an example, that the public-ID 
received in the INVTTE is n User-N_PUBLIC2 " , then the S- 
CSCF1 would find two P-CSCFs matching the condition above: 
P-CSCF1 and P-CSCF3 . 

Alternatively, for the purpose of finding out in the S-CSCF 
35 what P-CSCF (s) is (are) presently serving access for a 
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given user and a given public-ID, the S-CSCF can use the 
information stored in the aforementioned look-up table 
(Fig -7 [B] ) that relates public-IDs with the corresponding 
P-CSCF(s) . 

5 According to an embodiment of the present invention, the S- 
CSCF shall forward the INVITE to only one P-CSCF among the 
plurality of P-CSCFs through which a registration request 
containing said public-ID was granted from said S-CSCF . So, 
in the specific case cited as example, the S-CSCF1 would 
10 select one P-CSCF among P-CSCFl and P-CSCF2 and forward the 
INVITE to the selected P-CSCF. 

According to a further alternative embodiments, in case 
information related to a plurality of P-CSCFs is found 
through which a registration request containing said 

15 public-ID was granted from said S-CSCF, the session request 
(INVITE) is forwarded from said S-CSCF either: 
simultaneously or sequentially to more than one P-CSCF 
among the plurality of P-CSCFs. This is the case depicted 
in steps 5 and 7 of fig. 8, in which the INVITE is forwarded 

20 (simultaneously or sequentially) to P-CSCFl and P-CSCF3 , 
since (as assumed by the registration ^example cited 
previously) a registration request was requested (steps 5 
and 17 in Fig. 5) from said P-CSCFs indicating the same 
public-ID as the one received in the INVITE (User- 

25 N_PUBLIC2 ) . 

When, according to an alternative embodiment, the INVITE is 
forwarded from the S-CSCF simultaneously to more than one 
of said plurality of P-CSCFs, as soon as the session is 
awarded (e.g.: reception of SIP response code "200 OK" from 
30 one of said P-CSCFs), the S-CSCF can tear down the session 
requests it had sent to the other P-CSCFs <e.g.: sending a 
SIP cancel request "CANCEL" to said P-CSCFs) . 

For the sequential sending of the INVITE from the S-CSCF to 
more than one of said plurality of P-CSCFs, according to 
35 another alternative embodiment, a similar method as the one 
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described before for the sequential sending from the I-CSCF 
can apply until a positive response code (such as "200 OK") 
is received. I.e.: the S-CSCF sends the INVITE to a first 
P-CSCF among said plurality of P-CSCFs and start a timer 
5 associated to said sending. At time-out of said timer, or 
upon reception of a negative response (e.g.: a SIP response 
code "4XX"), it shall forward the INVITE to a second P- 
CSCF, etc.; thus proceeding correspondingly with the 
subsequent P-CSCFs . Optionally, the S-CSCF can tear down 
10 the session request it forwarded to a given P-CSCF at time- 
out (e.g.: sending a SIP cancel request "CANCEL" to said P- 
CSCF) . 

[0065] Upon reception of a session request (INVITE) in a 
P-CSCF (e.g.: at steps 5 or 7 of Fig. 8), said P-CSCF finds 
15 out in the address information (e.g.: IP-Addr) it keeps 
related to the terminals (UEs) it is serving access, the UE 
(or plurality of UEs) from which a registration was 
requested (REGISTER) and granted (2 00 OK) through said P- 
CSCF that contained the public-ID received in said INVITE. 
20 Alternatively, for the purpose of finding out in the P-CSCF 
what UE(s) said P-CSCF is serving access that 'got a granted 
registration indicating said public-ID, the P-CSCF can use 
the information stored in the aforementioned look-up table 
(Fig. 7 [C] ) that ''relates public-IDs with the corresponding 
25 UE ! s addresses. 

Then, according to an embodiment of the present invention, 
said P-CSCF forwards the received INVITE to one UE, among 
the plurality of UEs it is serving access that got a 
granted registration using the same public-ID as the one 
30 received in the INVITE. 

Going on with the specific case cited as example, in which 
"User-N_PUBLIC2" is received as public-ID in the INVITE; 
then P-CSCF1 would find the address of UE1 (IP-ADDR UEl) , 
while P-CSCF3 would find the address of UE3 (IP-ADDR UE3) . 
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Subsequently, in step 6 P-CSCFl would forward the INVITE to 
UEl, and P-CSCF would forward the INVITE to UE3 in step 8. 
However, regardless the specific case cited as example, at 
reception of an INVITE in a given P-CSCF, a plurality of 
I 5 ues could be found matching the condition above (e.g.: if 

UEl and UE3 got a registration through the same P-CSCF 
indicating the same public-ID in the REGISTER) . In this 
case, and according to further alternative embodiments of 
the present invention, said P-CSCF would forward said 
10 INVITE, either: simultaneously or sequentially, to more 
than one UE among said plurality of UEs . 

According to an alternative embodiment, the INVITE is 
forwarded from the P-CSCF simultaneously to more than one 
of said plurality of UEs. In this case, as soon as the 

15 session is awarded (e.g: reception of SIP response code 
"2 00 OK" from one of said UEs), the P-CSCF can tear down 
the session requests it had sent to the other UEs (e.g.: 
sending a SIP cancel request "CANCEL" to said UEs) . 
If, according to further another alternative embodiment, 

20 the INVITE is forwarded from the P-CSCF sequentially to 
more than one of said plurality of UEs, a similar method as 
the one described before for the sequential sending of 
INVITE from a I-CSCF or from a S-CSCF can also apply in the 
P-CSCF until positive response code (such as "200 OK") is 

25 received. Optionally, the P-CSCF can tear down the session 
request it forwarded to a given UE at time-out (e.g.: 
sending a SIP cancel request "CANCEL" to said UE) . 

[0066] A given user who has got multiple active 
registrations (multi-registered user) can become de- 

30 registered in a similar manner as described previously with 
reference to the state-of-the-art de-registration 
procedures. However, given that for a multi-registered user 
according to this invention there will be one independent 
entry per active registration in the location data of the 

35 SD register that corresponds to said user, only the right 
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entry in said location data shall be deleted in a de- 
registration procedure; remaining active all the other 
registrations of said user (if any other exist) . 
For instance, using as a reference location data shown in 
Fig. 6 for USER-N, as well as the public and private IDs 
used in the specific multiple registration exemplified in 
Fig. 5; in case of a user-initiated de-registration 
requested from UE1, only the first entry depicted in the 
location data of Fig. 6 would be erased {"S-CSCFl.HOMEl.NET 
{User-N_PUBLIC2 , User-N_PRIVATE1}» ) , since said entry will 
be the only one matching the public-ID and private-ID 
indicated in the de-registration request (i.e.: as cited 
previously, a similar message REGISTER as the one used in 
the registration, comprising the same private and public 
IDs, but indicating now an "Expire" header of "zero"); 
however, the other registrations (S-CSCF2. HOME1 .NET {User- 
N_PUBLIC1, User-N_PRIVATE2}"; and " S-CSCF1 . HOME1 .NET (User- 
N_PUBLIC2 , User-N_PRIVATE3}") would remain active, thus 
still allowing said user (USER-N) to receive incoming 
sessions from other parties. Similarly only the data stored 
in S-CSCF and P-CSCF related to the registration which is 
now de-registered shall be deleted. So, for the case of de- 
registration cited above as an example (i.e.: UE1 request a 
de-registration) , P-CSCF1 will delete the previously stored 
information that bound the public and private IDs used in 
the registration (User-N_PUBLIC2 , User-N_PRIVATE1) with 
the address of the UE that requested said registration (IP- 
ADDR UEl) ,- and S-.CSCFl will delete the previously stored 
information that bound the public and private IDs used in 
the registration (User-N_PUBLIC1, User-N_PRIVATE1) with the 
P-CSCF serving the access to said registration (P-CSCFl) ; 
however, S-CSCF would keep the data related to the other 
registration that, according to the example, it is serving 
for the same user (User-N_PUBLIC2 and User-N_PRIVATE3 , 
bound with P-CSCF3), thus being still able to serve session 
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control for further incoming sessions revested from other 
parties that are addressed to the public-ID "User- 
N_PUBIiIC2 " . 
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CLAIMS 



1. A method for handling multiple registration of, at 
least, one user, in a telecommunications system 
requiring to manage information related to the location 
of said user and related to at least one public identity 
and one private identity, that belong to the subscriber 
data (SD) of a single subscription of said user in said 
system and that identify said user in said system, 

the method characterized in that it further comprises 
the step of: 

storing, assigned to said subscription ia said 
telecommunications system, a plurality of private 
identities related to the subscriber data of said user 
in said system. 

2. A method according to claim 1, wherein said plurality of 
private identities are stored in the home server entity 

(HSS) assigned to the subscription of said user in said 
telecommunications system that stores the subscriber 
data of said user in said system. 

3. A method according to claims 1 or 2, further comprising 
the following steps for handling the multiple 
registration process of said user in said system: 

receiving subsequent registration requests 
(REGISTER) , each registration request requesting to 
attach a subsequent terminal (UE1,UE2 ,UE3) to said 
telecommunications system for said subscription; wherein 
each one of said subsequent registration requests 
contains, at least: 

a public identity associated to said user among the 
plurality of public identities associated to the 
subscription of said user, 

a private identity among the plurality of private 
identities associated to the subscription of said 
user; and 

processing each of said received subsequent 
registration requests according to the public identity 
and private identity received on each of said subsequent 
registration requests. 

4. A method according to claim 3, wherein the step of 
processing each of said subsequent registration requests 
comprises the steps of : 

receiving the registration request (REGISTER) in an 
interrogating server entity (I-CSCF) ; 
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sending from said interrogating server (1-CSCF) a 
registration query (CX-QUERY) to said home server (HSS) , 
wherein said registration query contains, at least, said 
received public identity and said received private 
5 identity; 

~ verifying in said home server (HSS) if said user is 

p already registered with said private identity; 

providing from said home server (HSS) to said 
interrogating server (I-CSCF) information for further 
10 handling said registration request; 

assigning a session-control server entity (S-CSCF) 
for serving session control for further sessions 
involving said user for said public identity and said 
private identity; 

15 granting (200 OK) the registration of said user ^ 

from said subsequent terminal in said telecommunications 
system. 

5. A method according to claim 4, wherein each one of said 
registration requests further contains information 

20 related to the first-contact-point server entity (P- 

CSCF1 , P-CSCF2 , P-GSCF3 ) serving the access of said 
subsequent terminal to said system. 

6. A method according to any of claims 4 or 5, wherein said 
information for further handling said registration 

25 request contains one or any combination among: 

a registration status indication stating if said 
user is not registered with said received private 
identity; 

the capabilities required for a session-control 
30 server (S-CSCF) in order to support session control for 

further sessions involving said user for said public 
identity and said private identity; 

a list containing information related to one or 
more of the plurality of session-control servers (S- 

35 CSCF1 , S-CSCF2 , S-CSCF3 ) that are already assigned to 

serve session control to said user for any of the public 
and private identities associated to the subscription of 
said user; said list being empty if there is no 
session-control server assigned yet to serve session 

40 control to said user for any of the public and private 

identities associated to said subscription. 

7. A method according to claim 6, wherein said list related 
to session-control servers (S-CSCF1, S-CSCF2 , S-CSCF3 ) 
contains information related to only one session control 

45 server (S-CSCF) that is already assigned to serve 
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session control to said user for said received public 
identity and any of the private identities associated to 
the subscription of said user. 

8. A method according to any of claims 4 to 7 , wherein the 
step of assigning a session-control server (S-CSCF) 
comprises the step of: 

selecting in said interrogating server (I-CSCF) a 
session control server (S-CSCF) , and forward said 
subsequent registration request (REGISTER) to it. 

9. A method according to claim 8, wherein the interrogating 
server (I-CSCF) selects a session-control server (S- 
CSCF) based on said capabilities required for a session- 
control server. 

10. A method according to claim 8, wherein the 
interrogating server (I-CSCF) selects a session-control 
server (S-CSCF) from said list of session-control 
servers (S-CSCF1, S-CSCF2 , S-CSCF3 ) , if said list is not 
empty . 

11. A method according to any of claims 8 to 10, further 
comprising the steps of: 

sending (CX-PUT) from said selected session control 
server (S-CSCF1, S-CSCF2 , S-CSCF3) to said home server 
(HSS) information related to said selected session- 
control server (S-CSCF1, S-CSCF2 , S-CSCF3 ) , said received 
public identity and said received private identity; 

storing in said home server (HSS) information 
stating that said selected session-control server (S- 
CSCF1, S-CSCF2 / S-CSCF3 ) is assigned to serve session 
control for further sessions related to said user for 
said received public identity and said received private 
identity; said information being stored in addition to 
any eventual previously stored information concerning to 
any other session-control server (S-CSCF1, S-CSCF2,S- 
CSCF3) already assigned to serve session control for 
further sessions related to said user for any public 
identity and any private identity assigned to the 
subscription of said user. 

12 . A method according to any of claims 4 to 11 wherein the 
first-contact-point server (P-CSCF1, P-CSCF2 , P-CSCF3) 
binds a given public identity with a list containing the 
individual address (IP-ADDR) of each terminal that have 
got a granted registration through it (2 00 OK) and have 
used said public identity in the granted registration. 
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13 A method according to any of claims 4 to 12 wherein the 
session-control server (S-CSCFl, S-CSCF2 , S-CSCF3 ) binds 
a given public identity with a list containing 
information of each first-contact-point server (P-CSCF1, 

5 P-CSCF2, P-CSCF3) trough which a registration containing 

said public identity was granted (200 OK) from said 
session-control server. 

14 A method according to any of claims 4 to 13 wherein the 
home server (HSS) binds at least one public identity 

10 associated to the subscription of a given user, among 

the plurality of public identities associated to the 
subscription of said user in said system, with a list 
containing information related to each session-control 
server (S-CSCF, S-CSCF2 , S-CSCF3) that was stored (CX- 

15 PUT) in said home server as assigned to serve session 

control for further sessions related to said user for 
said public identity. 

15. A method for handling a session establishment towards a 
given user, comprising the step of: 
20 receiving a session request (INVITE) requesting to 

establish a session towards said given user, wherein 
said session request contains a public identity 
associated to the subscription of said given user; 

characterized in that it further comprises the next step 
25 for handling multiple session establishment towards a 

given user registered according to any of claims 3 to 
14: 

processing said session request according to the 
plurality of terminals (UEl, UE2 , UE3 ) that have a 
30 registration granted (200 OK) for said subscription. 

16 A method according to claim 15, wherein the step of 
processing said session request (INVITE) comprises the 
step of: 

forwarding said session request to one terminal 
35 (UE) among said plurality of terminals (UE1,UE2,UE3) ; or 

forwarding said session request sequentially to 
more than one of said plurality of terminals 
(UE1,UE2,UE3) , until said session is awarded by one of 
them; or 

40 forwarding said session request simultaneously to 

more than one of said plurality of terminals 
(UE1,UE2,UE3) . 

17. A method according to claim 15, wherein the step of 
processing said session request comprises the steps of: 
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receiving a session request (INVITE) requesting to 
establish a session towards said given user, wherein 
said session request contains a public identity 
associated to the subscription of said user; 

sending a location request query (CX- LOCATION- 
QUERY) from an interrogating server entity (I-CSCF) to 
the home server entity (HSS) of said given user, wherein 
said request contains said public identity; 

answering said query, from the home server (HSS) of 
said given user to said interrogating server (I-CSCF) ; 
the answer comprising information related to one 
session-control server entity (S-CSCF) that is assigned 
to serve session control to said given user for said 
received public identity, among the plurality of 
session-control servers (S-CSCF1, S-CSCF2, S-CSCF3) that 
are assigned to serve session control to said user for 
said received public identity and any of the private 
identities associated to said subscription; 

forwarding said session request (INVITE) from said 
interrogating server (I-CSCF) to said session-control 
server (S-CSCF) , wherein said session request contains 
at least said received public identity; 

forwarding said session request (INVITE) from said 
session-control server (S-CSCF) to one first-contact- 
point server entity (P-CSCF) among the plurality of 
first-contact-point servers (P-CSCF1, P-CSCF2 , P-CSCF3 ) 
trough which a registration containing said public 
identity was granted (2 00 OK) from said session-control 
server (S-CSCF) , wherein said session request contains 
at least said received public identity; 

forwarding said session request (INVITE) from said 
first-contact-point server (P-CSCF) to one terminal 
(UE) , among the plurality of terminals (UE1, UE2,UE3) 
said first-contact-point server is serving access that 
got a granted registration (2 00 OK) using said public 
identity. 

18. A method according to claim 17, wherein the answer 
from the home server (HSS) to said interrogating server 
(I-CSCF) comprises information related to only one 
session-control server (S-CSCF) among the plurality of 
servers (S-CSCFl, S-CSCF2,S-CSCF3) that are assigned to 
serve session control to said user for any public 
identity and any of the private identities associated to 
said subscription. 

19. A method according to claim 17, wherein the answer 
from the home server (HSS) to said interrogating server 
(I-CSCF) comprises a list containing information related 
to more than one session-control server (S-CSCF) among 
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the plurality of servers (S-CSCFl, S-CSCP2, S-CSCF3 ) 
that are assigned to serve session control to said user 
for said received public identity and any of the private 
identities associated to said subscription. 

2 0 A method according to claim 17, wherein the answer 
from the home server (HSS) to said interrogating server 
(I-CSCF) comprises a list containing information related 
to more than one session-control server (S-CSCF) among 
the plurality of servers (S-CSCFl, S-CSCF2 , S-CSCF3) 
that are assigned to serve session control to said user 
for any public identity and any of the private 
identities associated to said subscription. 

21. A method according to claims 19 or 20, wherein the 
interrogating server (I-CSCF) : 

forwards said session request (INVITE) to only one 
session-control server (S-CSCF) among the plurality of 
session-control servers (S-CSCFl , S-CSCF2 , S-CSCF3 ) 
received from the HSS; or 

forwards said session request (INVITE) sequentially 
to more than one session-control server (S-CSCF) among 
the plurality of session-control servers (S-CSCFl, S- 
CSCF2 , S-CSCF3 ) received from the HSS, until said session 
is awarded by one of them; or 

forwards said session request (INVITE) 
simultaneously to more than one session-control server 
(S-CSCF) among the plurality of session-control servers 
(S-CSCFl, S-CSCF2, S-CSCF3) received from the HSS. 

22. A method according to any of claims 17 to 21 wherein 
the session-control server (S-CSCF) : 

forwards the session request (INVITE) sequentially 
to more than one first-contact-point server (P-CSCF) 
among said plurality of first-contact-point servers (P- 
CSCFl, P-CSCF2 , P-CSCF3), until said session is awarded 
by one of them; or 

forwards the session request (INVITE) 
simultaneously to more than one first-contact-point 
server (P-CSCF) among said plurality of first-contact- 
point servers (P-CSCFl, P-CSCF2 , P-CSCF3). 

23 . A method according to any of claims 17 to 22 wherein 
the first-contact-point server (P-CSCF) : 

forwards the session request (INVITE) sequentially 
to more than one terminal (UE) among saLd plurality of 
terminals (UE1 , UE2 , UE3 ) , until said session request is 
awarded by one of them; or 
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forwards the session request (INVITE) 
simultaneously to more than one terminal (UE) among said 
plurality of terminals (UE1,UE2,UE3) . 

24. A telecommunications system for handling multiple 
registrations of , at least, one user, said system 
comprising: 

storage means arranged to store subscriber data (SD) 
related to a single subscription of said user in said 
system, said subscriber data (SD) comprising, at least: 
a single private identity and at least one public 
identity, that identify said subscription of said user 
in said system; 

processing means arranged to process a received 
registration request (REGISTER) for said user according 
to said public identity and according to said single 
private identity received on said registration request; 

the system characterized in that: 

said storage means are further arranged to store a 
plurality of private identities related to the 
subscriber data of said user in said system; and 

said processing means are further arranged to process 
subsequent registration requests (REGISTER) received for 
said user according to the public identity and according 
to the private identity received on each of said 
registration requests, among said plurality of private 
identities . 

25. A telecommunications system according to claim 24, 
further comprising 

a home server entity (HSS) arranged to contain said 
storage means; 

and wherein said processing means consist of: 

a first-contact-point server entity (P-CSCF) arranged 
to serve the access of said user to said system; 

an interrogating server entity (I^CSCF) arranged to 
serve the initial handling of transactions involving 
said user; and 

a session-control server entity (S-CSCF) arranged to 
serve session control services for sessions involving 
said user. 

26. A telecommunications system according to claim 25, 
wherein: 

said home server (HSS) is further arranged to verify 
if each subsequent registration request of said user 
contains one of the private identities assigned to said 
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user among said plurality of private identities of said 
user; 

said home server (HSS) is further arranged to store 
information related to a plurality of session-control 
servers (S-CSCFl, S-CSCF2 , S-CSCF3 ) that are assigned to 
serve session control for said user for any of the 
plurality of private identities and public identities 
assigned to the subscription of said user; 

said home server (HSS) is further arranged to provide 
to an interrogating server (I-CSCF) information for 
handling each subsequent registration request; said 
information comprising one or any combination thereof 
among : 

a registration status indication stating if said user 
15 i s not registered with said received private identity; 

the capabilities required for a session-control server 
(S-CSCF) in order to support session control for 
further sessions involving said user for said public 
identity and said private identity; 
20 a list containing information related to one or more 

of the plurality of session-control servers (S- 
CSCF1 , S-CSCF2 , S-CSCF3 ) that are already assigned to 
serve session control to said user for any of the 
public and private identities associated to the 
subscription of said user; said list being empty if 
there is no session-control server assigned yet to 
serve session control to said user for any of the 
public and private identities associated to the 
subscription of said user; 

said interrogating server (I-CSCF) is further arranged 
to select a session-control server (S-CSCF) to serve a 
registration request of said user, among said plurality 
of session-control servers (S-CSCFl, S-CSCF2 , S-CSCF3 ) . 

27 A telecommunications system according to claims 25 or 
26, wherein said home server (HSS) is further arranged 
to bind at least one public identity associated to the 
subscription of a given user, among the plurality of 
public identities associated to the subscription said 
user in said system, with a list containing information 
related to each session-control server (S-CSCF, S-CSCF2, 
S-CSCF3) that is assigned to serve session control for 
further sessions related to said user for said public 
identity.. 



25 



30 



35 



40 



45 



28 



. A telecommunications system according to any of claims 
25 to 27, wherein said session-control server ( S-CSCFl , 
S-CSCF2, S-CSCF3) is further arranged to bind a given 
public identity with a list containing information of 
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each first-contact-point server (P-CSCF1, P-CSCF2 , P- 
CSCF3) trough which a registration containing said 
public identity was granted (200 OK) from said session- 
control server. 

29. A telecommunications system according to any of claims 
25 to 28, wherein a first-contact-point server (P-CSCF) 
is further arranged to bind a public identity with a 
list containing the individual address (IP-ADDR) of each 
terminal (UE1 , UE2 , UE3 ) that have got a granted 
registration through it (2 00 OK) and have used said 
public identity in the granted registration. 

30. A telecommunications system as described in any of 
claims 24 to 29 for handling session establishment 
towards, at least, one user, said system further 
comprising: 

processing means arranged to process a received 
session request (INVITE) , said session request 
containing a public identity associated to the 
subscription of said user, according to a terminal (UE) 
that have a registration granted (200 OK) for said 
subscription in said system; 

the system characterized in that: 

said processing means are further arranged to process 
said session request (INVITE) according to a plurality 
of terminals , (UE1,UE2,UE3) that have a registration 
granted (200 ,OK) for said subscription in said system. 

31. A telecommunications system according to claim 30, 
wherein said processing means are further arranged to: 

forward said session request (INVITE) to one terminal 
(UE) among said plurality of terminals (UEl , UE2 , UE3 ) ; or 

. forward said session request ( INVITE ) sequentially to 
more than one of said plurality of terminals 
(UE1,UE2,UE3) , until said session is awarded by one of 
them; or 

forward said session request (INVITE) simultaneously 
to more than one of said plurality of terminals 
(UE1,UE2,UE3) . 

32. A telecommunications system according to claim 30, 
wherein said processing means consist of : 

a home server entity (HSS) , a first-contact-point 
server entity (P-CSCF) , an interrogating server entity 
(I-CSCF), and a session-control server entity (S-CSCF) ; 

as described in any of claims 25 to 29. 
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33. A telecommunications system according to claim 32, 
wherein: 

said home server (HSS) is further arranged to provide 
to an interrogating server (I-CSCF) information for 
5 handling a session request (INVITE), said information 

comprising information related to, at least, one 
session-control server (S-CSCF) among the plurality of 
' . session-control servers ( S-CSCFl , S-CSCF2 , S-CSCF3 ) that 
are assigned to serve session control to said user for a 
10 given private identity and a given public identity among 

the plurality of private identities and public 
identities assigned to the subscription of said user; 

said interrogating server (I-CSCF) is further arranged 
to forward a session request (INVITE) to, at least, one 
15 session-control server (S-CSCF) of said plurality of 

session-control servers (S-CSCFl , S-CSCF2 , S-CSCF3 ) ; 

said session-control server (S-CSCF) is further 
arranged to forward a session request (INVITE) to, at 
least, one first-contact-point server (P-CSCF) among the 

20 plurality of first-contact-point servers (P-CSCFl, P- 

CSCF2 , P-CSCF3) trough which a registration containing a 
given public identity was granted (200 OK) from said 
session-control server; 

said first-contact-point server (P-CSCF) is further 

25 arranged to forward a session request (INVITE) to, at 

least, one terminal (UE) among the plurality of 
terminals (UEl,UE2 ,UE3 ) that have got a granted 
registration -through it (200 OK) and have used a given 
public identity in the granted registration. 

30 34. A telecommunications system according to claim 33, 

wherein said interrogating server (I-CSCF) is further 
arranged to: 

forward said session request (INVITE) simultaneously 
to more than one session-control server (S-CSCF) among 
35 said plurality of session-control servers (S-CSCFl, S- 

CSCF2,S-CSCF3) ; or 

forward said session request (INVITE) sequentially to 
more than one session-control server (S-CSCF) among said 
plurality of session-control servers (S-CSCFl, S-CSCF2 , S- 
40 CSCF3), until said session is awarded by one of them. 

35. A telecommunications system according to claims 33 or 
34, wherein said session-control server (S-CSCF) is 
further arranged to: 

forward said session request (INVTTE) simultaneously 
45 to more than one first-contact-point server (P-CSCF) 

among said plurality of f irst-contact-point servers <P- 
CSCF1, P-CSCF2, P-CSCF3) ; or 
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forward said session request (INVITE) sequentially to 
more than one f irst-contact-point server (P-CSCF) among 
said plurality of first-contact-point servers (P-CSCF1, 
P-CSCF2, P-CSCF3), until said session is awarded by one 
5 of them. 



36. A telecommunications system according to any of claims 
33 to 35, wherein said first-contact-point server (P- 
CSCF) is arranged to: 

forward said session request (INVITE) simultaneously 
10 to more than one terminal (UE) among said plurality of 

terminals (UEl , UE2 , UE3 ) ; or 

forward said session request (INVITE) sequentially to 
more than one terminal (UE) among said plurality of 
terminals (UEl , UE2 , UE3 ) , until said session is awarded 
15 by one of them. 



03005669A1J > 



WO 03/005669 



1/8 



PCT/EP02/06557 




u 

CD 
CO 

Q- 



UJ 

D) 

CM 

CD 

u 

<D 
CO 



-Q 



CO 



c 

CD 

i— 
© 
CO 
13 

a. 



43 

-H 
M 
Pi 



0 
U 

g 

-H 



© 

© 

CO 



1 



c 

o 



o 

CO 

.a 

CO 



SUBSTITUT€ SHEET {RULE 26) 



IMCrWNIN *AAIt~\ 



WO 03/005669 



2/8 



PCT/EP02/06557 



3 
a. 

X 

o 

CD 



Q_ 

CO 
CD 

dc 



Q_ 

o 



LU 

> 



CD 

a 

CO 



W 
CD 

CD 

o 

X 

o 



DC 
LU 

92 

LU 
DC 

LO 



o 

o 

CO 



c 

o 

n 

go 

CNI 



c 

•2 Q_ 

§8 
•3?. 

8 § 



LU 

> 



u 
o 

-H 
U 
Pi 



LU 

> 



DC 
LU 

o 

LU 

DC 

c\i 



O 

o 
o 

OJ 

ai 



CN 

g 

-H 



o 

o 



LU 



CO 



SUBSTITUTE SHEET (RULE 26) 



BNSDOCID: <WO 0300S669A1 J_> 



WO 03/005669 



3/8 



PJCT/EP02/06557 



C\i 

o a 

*> 

0) CD 

3 3 



CO 

g 
i 

g 
— i 

CO 



< 

Q 

2: 
g 

o 



LLi 
Q 



CD 

3 



g 

UJ 

cc 

CL 

J 



CD 

1 



CD 

3 



i 
1 

CO 



< 

Q 



Q 



•§ 

! 

CD 
03 

§ 

6 
-92 

! 

■8 
s 

CL 

In. 
P 

3 



Q 

CC 

in 



u 
o 

-H 
M 
Of 

• 

(D 

a 

•H 




CO 



SUBSTITUTE SHEET .(RULE 26) 



WO 03/005669 



4/8 



PCT/EP02/06557 



CM 



CD 
CO 

ZJ 



co 
CL 



M 



•H 



c 



C 
T3 



CO 

f 




o 
o 

CO 
CO 



SUBSTITUTE SHEET (RULE 26) 



WO 03/005669 



PCT/EP02/06557 



5/8 




in 

o 
u 

& 

fa 



SUBSTITUT€ SHEET -(RULE 26) 



WO 03/005669 



6/8 



PCT/EP02/06557 



3 



CO 

o 
g 

CO 

ZD 



3 
1 



P 3 

3 



"Y" 



s 



9* 

3 



2 
g 

CL 



J 



3 



■fi 



3 



o 

1 

U- 



LU 
O 



5 



3 
8 

I 

3 



i 

i 



i 

Q 

o 

§ 

o 



3 



a. 



03 

3 



i 
i 

to 



CO 



3 
I 

0. 



P 

3 



ft 



b b fc 



I 

CO 



S 




SUBSTITUTE SHEET (RULE 26) 



BNSDOCID: <WO O3005663A1 I > 



WO 03/005669 



PCT/EP02/06557 



7/8 




SUBSTITUTE SHEET (RULE 26) 



RM«nnrar><wo O3005669A1 i > 



WO 03/005669 



PCT/EP02/06557 



8/8 




U 




> 




UJ 

> 




SUBSTITUTE SHEET (RULE 26) 



INSDOCID: <WO 03005669A 1 _l_> 



BEST AVAILABLEtCOPrYj 



fl 



INT^aATIONAL SEARCH REPORT 


Intemat^hl Application No 

PCT/EP 02/06557 


A. CLASSIFICATION OF SUBJECT MATTER 

IPC 7 H04L29/06 








According to International Patent Classification (IPC) or to both national classification and IPG 






B. HELDS SEARCHED 


Minimum documentation searched (classification system tallowed by classification symbols) 

IPC 7 H04L H04Q 


Documentation searched olber than minimum documentation to the extent that such documents are included In the fields searched 


Eleclronic data base consulted during the International search (name of data b£ 

EPO-Internal , WPI Data, PAJ, INSPEC 


tseand, where practical, search terms used) 


C. DOCUMENTS CONSIDERED TO BE RELEVANT 


Category 0 


Citation of document, with indication, where appropriate, of the relevant passages 


Relevant to claim No. 


X 
Y 


US 5 943 620 A (BOLTZ DAVID ET AL) 
24 August 1999 (1999-08-24) 

abstract 

column 2, line 11 - line 33 
column 4, line 58 -column 5, line 4 
column 5, line 61 -column 6, line 27 




1-3,15, 

16,24, 

30,31 

4-14, 
17-23, 
25-29, 
32-36 






•/- 






j y j Further documents are listed In the continuation of box C. 


[y j Patent ram By members are listed in annex. 


• Special categories of dted documents : 

'A* document defining the general state of the art which is not 

considered to be of particular relevance 
*E* eanier documenl but published on or after the international 

filing date 

•L" document which may throw doubts on priority daim(s) or 
which is cited to establish the publication date of another 
citation or other special reason (as specified) 

a O" document referring to an oral disclosure, use, exhibition or 
other means 

•p* document published prior to the international filing date but 
later than the priority date claimed 


T* later document published alter the International filing date 
or priority date and not in conflict with the application but 
cited to understand the principle or theory underlying the 
invention 

•X* document of particular relevance; the claimed Invention 
cannot be considered novel or cannot be considered to 
involve an inventive step when the document is taken alone 

■Y* document of particular relevance; the claimed invention 
cannot be considered to Involve an inventive step when the 
document is combined with one or mora other such docu- 
ments, such combination being obvious to a person skilled 
In the art 

•&* document member of the same patent family 


Dale of the actual completion of the international search 


Date of maffing of the international search report 


18 September 2002 


09/10/2002 




Name and mailing address of the ISA 

European Patent Office, P.B. 5818 Patent laan 2 
NL - 2280 HV Rljsw1]k 
Tel (+31-70) 340-2040, Tx. 31 651 epo n), 
Fax (+31-70) 340-3016 


Authorized officer 

Tous Fajardo, J 



Form PCT/lSftGio(second sheet) (Jury 1992) 



BESTAVAMBILE COPY 



INTI 



ATIONAL SEARCH REPORT 



intemat^j^t Application No 

PCT/EP 02/06557. 



C(Continuatlon) DOCUMENTS CONSIDERED TO BE RELEVANT 



Category ° Citation of document, with indication .where appropriate, of the relevant passages 



Relevant to claim No. 



WO 99 55107 A (HIRZEL WERNER ;SWISSC0M AG 
(CH); HEUTSCHI WALTER (CH); STADELMANN) 
28 October 1999 (1999-10-28) 
abstract 

page 2, line 28 -page 3, line 17 
page 4, line 4 - line 7 
page 4, line 12 - line 14 
page 6, line 23 -page 7, line 3 
page 9, line 10 - line 12 
figure 2 

W0 98 24257 A (NOKIA TELECOMMUNICATIONS 0Y 
;UUSITAL0 MARKKU (FI)) 
4 June 1998 (1998-06-04) 
page 2, line 24 - line 29 
page 6, line 5 - line 8 

3GPP: "3GPP TS 23.228 V5.1.0" 
3RD GENERATION PARTNERSHIP PROJECT; 
TECHNICAL SPECIFICATION GROUP SERVIES AND 
SYSTEM ASPECTS; IP MULTIMEDIA (IM) 
SUBSYSTEM - STAGE 2, 

- June 2001 (2001-06) pages 1-135, 
XP002213956 

cited in the application 
the whole document 



1,2,24 



1,2,24 



4-14, 
17-23, 
25-29, 
32-36 



Form PCT/ISA/210 (ccntriuation of eeoond shoal) (July 1892) 



RNSOOCID: <WO 0300S66SA1 I > 



BEST AVAILABLE COPY 



INT 



ATIONAL SEARCH REPORT 

atlon on patent family members 



Intern at! 



No 



>t^K Application 

PCT/EP 02/06557 



Patent document 




Publication 




Patent family 




Publication 


cited in search report 




date 




member(s) 




date 


US 5943620 


A 


24-08-1999 


AU 


735865 


B2 


19-07-2001 








AN 


7852398 A 


03-07-1998 








DD 
DF\ 


9713883 A 


£.7 Ul lUUw 










1245617 A 


Cm. %S W t— l—\J\J\J 








L/C. 


69713383 


Dl 










FP 

tr 


0943214 


A2 


C\C U? 1777 








un 
WU 


9826626 A2 


1 ft-fifi— 1 QQft 

lO UO iJJU 


WO 99551 0/ 


A 
A 


^o— iu— lyyy 


AT 
A 1 


201948 


T 


ID UO lUUI 








Al 1 
RU 


747302 


B2 


1U US tUuc 








Al 1 
AU 


2824399 


A 


flA-l 1 —1 QQQ 

UO IX 17 77 








RP 
DK 


9906361 


A 


17 W7 £UUU 








Lin 
WU 


9955107 


Al 


LO IU 1777 








UN 


1263682 


T 


lO l/o tUUU 








nr 
Uh 


59900110 


Dl 


1 9— n7— 90,0.1 








UN 


990364 


T3 


17— nQ— ?fim 

1 / U7 tVUl 








CD 

tr 


0990364 


Al 


UD UH tUUU 








to 


2159988 


T3 










HU 


0003259 


A2 


28-02-2001 








JP 


2002511223 


T 


09-04-2002 








un 


996146 


A 










NC. 


501860 


A 


^1-fift-^nm 

Jl Do tUUl 








Dl 

ru 


337282 


Al 


XH UO cUUU 








DT 

r l 


990364 


T 










TD 

1 K 


200000205 


Tl 


?i — no— ?nnn 

l1 U7 tUUU 








7A 


9907597 


A 


U UO tUUU 


WO 9824257 


A 


' a'/i * Ate i hho 
04-06— 199o 




964732 


A 


2cu-n^— 1QQ& 1 








Al 1 

AU 


724391 


B2 


tUUU 








AU 


5122598 A 


22-06-1998 








BR 


9713150 


A 


08-02-2000 








CN 


1238894 


A 


15-12-1999 








EP 


0945035 


Al 


29-09-1999 








WO 


9824257 


Al 


04-06-1998 








JP 


2001504666 


T 


03-04-2001 








US 


6366777 


Bl 


02-04-2002 








ZA 


9709934 


A 


25-05-1998 





Form PCT/ISW2IO fratani Iam3y annex) (July 1932) 



.YqOO iUg/UiAVA T8BB 



v 4 ? 



THIS PAGE BLANK (usptoj 



